


Institutional Archive of the Naval Postgraduate School 





Calhoun: The NPS Institutional Archive 
DSpace Repository 


Theses and Dissertations 1. Thesis and Dissertation Collection, all items 


1987-06 


Design, implementation and evaluation of an 
operating system for a network of transputers 


Cordeiro, Mauricio de Menezes 


http://ndl.handle.net/10945/22732 
Copyright is reserved by the copyright owner 


Downloaded from NPS Archive: Calhoun 


Calhoun is the Naval Postgraduate School's public access digital repository for 


/ (8 D U DLEY research materials and institutional publications created by the NPS community. 
«ist : Calhoun is named for Professor of Mathematics Guy K. Calhoun, NPS's first 


NY KNOX appointed — and published -- scholarly author. 

; | LIBRARY Dudley Knox Library / Naval Postgraduate School 

411 Dyer Road / 1 University Circle 
Monterey, California USA 93943 





http://www.nps.edu/library 


ys! 


hore 
ido a 
seas inate 

oo 

Dei ier 

. Bred gp 

tay ea’ gry 

fives 

\ seg 

4 bpod, 

yt 

ar PY 

lS as 
--A 

Lr 

i] 

i 4 

is b, 

rit ag 

1 


















































































































© Peet 
Age od set sinh 
ii eam 
etait. steeenaee 
re - Siok iets Cosateaees a * 
acs aati ‘ pst'tr) a0 A paucreeeengs wry) 
sai re centeit pr pie ido 
4: Cae or rds He ¢ ce way ueah fees 
vere rn: . ale nA 3 fants Jie: tee y? Mame toa 
aes or ees ote tel eS pbc taaca Be Saanedy he rd Fr 99-5) Ae 9 
Sea siakte * ra ; ite Ce ae & bye Soe er ee cpr rpetiend eae 
Sein icone oN mane? er AY ee Seeteamtcree Reems is 
Lr a ie Sa aa Ane easy et $e nd A 
gy noe ay egis ase uhicas Seba tase Aha beds is i sah tai <a tat Eee 
TARE Tage ptetedent Ne ahi eres daca nah SaaS a8 pie Be penis: mlelenen At ion: “is 
seas i vy Ror ) tab’ act arn Af +3 whee eles Atanas ier att we via cars ota 0 on ih) ice 
7 . it & a e-% Hh ae site Seated raed nae = » 4 aD * right BIS fe re 
t shyt ae die ~~ Wn re Se “it neon ov hse. Bettis ae Ierk tees of ra fe amare te exact et ° 
: i ‘ As ath -* L. e 
a pe | = a eo. abet bg | “sa, a rr ae, oh pe “43s a mt tei weet sae Risers 
a me hat 2 SS b A PL pants rhe Sak at site Rep aca be sty 
ee | Gri ry q 4 Lay shorty P Seer 4 tite. = aliet Pet ah aa hah es) 
1 +4 ‘ aa *s i Sea - Far ' aT > peor oe r Bars § hearth us mere? far : ued yt us fs sae ne tga tie sacs ss 
ot ave “Wh sa yh cepa Beds Mt yey. .) Tae NSA NA oh weet, Nels hel Feet tas ° as 
1 ne, a ce Wry new Me had Gules ne leaned re i (ik fee poor Le - omens * Aste: « 
! » + ‘a bas * ihe rire ak at mess a ee ene eer Pe una en yh 3a toot anges Hope crim 
cf a : fgets aes aie rites ied ue fo a parses fat 
i, s, , ‘ - 7 . n 7, » ie +f L ry] ‘oom. t, a4. . SS ty 
Pr ‘ I ed ONS. POT F Stage ean Tete: Rent area ati Rosie ho et ee ‘ a 
; a4 . . o , 5 ro \ iz Fi wk < aay rs Lean sar : cae Pe coai tes oy we red STi at Faby eet. pert, 
3 i aaa F oa 4 ~ ’ . fi - Bi t, ya “y 
ee : ' , ~  tiedagare vari Share, mires mes a tines 2 aah 1 preby | rote Sabend vibes = nse Peet bah 
“oe es aay oy ee | ne eth = fee hee aut tutte meencinerteate erat saailss. 
er the 4 : coat hae ays ‘yf elt Ow Ph sare Re ue tae mahal ae s 
i * ' 3 fibep ter > Me Lath th ne rap a Age a AS ir Aide hee very trad : iY Vineet eg o to te ‘eos 
1 1 7 . mada p yr vo As Sumy may akin Dare Ly Frey * goer ne 
3 r Y wha P : ? Eee Eee ane ari cane may Dae cast sins ry oe pte pepe 
: gear , ; ’ aL | “a SICH faye es hea ues FicNganl sane “ cane asst rape scash ie ll main ale 
a oT 2 s | “spt Bas i aks. se Were beaey att op tp a ue ae “ ey poe say er iahind es : es Vie! 
5 ‘ 4 My me ae a 4 1) dest, a ear ay gil, 14) tet yee “Se suey * Parra i tt, Pod ee ero 
tare rr. anes “ok Alms $3 vhs 2-8. ale eit § 2 wi 4 bang ray era ee jiarg’ be age, 
a 1 ‘ 2 40) rN nd agen x Sore ety be or - Seaiyet ay Beige Pye thie ey 
pot oe Save? iy 26a He ) “we phos Laban ae care rere pommel app esl 
y: ae "ibaa Pacman eres seth ae Satie oe 
. y meh WIE Ty Pas to desgetacary kor nays Was AN i) Daa! Afaeras 
P + ‘ 4 “ aad ce oate thitekah aay est _ Jue alipnae UG agar ove yr r 4 be 
4 ; ' ies, ¢ pointe 4 ahi oath $4'et 13 OL pats iat Bad i 
“, | 2 ye 1 vi ‘ Takes mabe Beak Pt sa ae Oy ae nee ¢ 
‘ ae =a beth utd Wie ve ae na yet Mette * % Diape dae 
' ame meas * 3 bet nace pt yy ied Les ogee each ty ; 
; oy fers, ¢ Sc e ee giles gicr Utero Sa ied 
ee ‘Gh ane ? 4 cay eat ‘af ; Sie Tod ee dyte ares mote 
| a | eis ae Ma i : reapers as see st 
- “ > r ? Cree ohe 
ae : ae 2 : esteny "hte ip ey ‘- ays > eH a pets, e Ty 
a re rt i Minane tata race fees Bh et sus 
: ; ; a “ os Wiassss oe ba bie Main ie. «te 
a Bibinr a, Der, 3 Rico 
" , ae pero ‘eee se ae ies ~ ne 
; i “6 1 a M65 jMouda res fn D eo th ve e oer. Ava mah SARS 
¢ , 2a “Aga a t he 4 fs 2 . 
Lee fies ey NaS Ay ropes a; Pete met ig 
‘. : Pat a: View f <eeeetet AY 4 & 
an . ee el TOC 1a ay neater ee caret - eS 
' ‘ . ep news pate aoe a Has a me o ) eae ra eee 1 
Boe ' in x wate ehets aT abe: ra ae ee 
boas. * K - 1 br #5 ied Ala faiaie hE re abe ty ey ier 2s noe a P wat es / tp een gat 
: : : , ‘sabe rt: | tad Batya sey oy Sites ud tee A) jae ae an ghey, soit Saas ES oh 
4 ohas : , of oa 22% Bee Hes gee ui late wad iat ay aa Pag ety pan SY ‘ sas M4 er iho Sess ick 
. . ® : a 4 Ai . ~ . > s , ay 
an ae SF in Wide ay Wethg ant had > Se piidbig: er elieats gals ¢ conn? i kaos sabi utes ies mahi 
ni ar = he ’ me AP ad ha! : % . 4 se! 's 64 ibe : xd bea, oor eine. : * a Es foo 8 thie k 
ie oes Li Mes epi 5 Te ree satan eee tenet ee 
' ns Ppt \c ' . ay ie 1 + eamite “i vty = &, 1) re < sal nih ws the ane ee ate as An Me ES roy ah Si eos i 
‘ ., ' Pas i mi 7 ave Le .t tay Ayal Kt - JAR ra é a oh NGS pi bstnsd y Py Hs ia cis pac ise oe § 
a ‘ i om ie =F ad taht he st al fly dy ets . < <5, + Ty igisal if Co, se ie: Borge Bowes mat, eet 3 
( ae ae Lite aia, 4 mre Ae gate ehh Ry ke > od See ‘ 
' an ms ‘ ~ one 1 are. bai aaa ¥ 4 OF : muy reels Beate ht Jane me ey ALS Oe Feacs g's ye Nr res ae 
; P < ’ ‘ vw Y, Nes! 5 1 ted ™ 4 toe b, * ey winder ig ee Meg hn Saas ee “ Moats 4 ee ™ eN M3 
‘ F ‘ on ee ? sh : S408 & R, i. ' = 0A Seton 2 int Le Mor £5. a Ta ee A PAS eR 
ere ae es eg ae PN Ses Re bemae PR ate dap Ee one dene, a 
ye ; b : ‘ ne Poe F sly sete ys ¥T cty, Cr Atte e Ve x Va@a2 of ?. o (eh 3 ek er, 77 Mya ea abet bal ie wa Mier tee 1 n Hegre zee ei 
: ae; ao 5 Aa oe fe | Ds Pe oY reat $43 rie + wd ob Sonhy ary 1 aatanaes eee ey 
"'s oe a: ee ae 4 wt vat oes “ai ae ada ferent ga pases ee J4) oe Ela isa oid: mee Site 
= Q Sap F a? : jah ¥ , : 4 
‘ ® . "Oa, z, x Mos { Pr] rae Lae’ 4 cae Pet Jem Ny: 144 Git. five 4 SP favs oes pt a hes 
: v D A he r ; ; i a sRaeAY 7 wails nop Hs nce i kat ign wiys ahs 4 
i 1 oR ’ ty ter ‘ ee ‘as = t “yay oye 4 Fey age: a ies He ' Ema lates dye igs oe ig, 
; ‘ : ‘ Wg Wa oes Aaa : ce rane se AS Bitte “d e Bi) 3 tN ir eas enews as ONS z sheer 73 oe ke 
’ Fat 4 1 type * . vad -. Cer gh rs rt i: 4 . panel ' ot ne 4 
' ¢ | ae} aa nie 4 La p agi? “2 ote TAS. ag 4a ¥h Fe ’ ¢ f ve Mette ° F 4 
pe ae - Mey a 61 neh $e ole’ iat be fags easery fe Ficad bi The i ae ace Ba qs *s ari Papers |, 
' i r « at I - ae ~ Kore * ‘eye ats, fagenthh Mes \hb aot . es | Att hy&4 ie Ye wth iy i pence * J a 
- ' - ' $° if ' be 1 oh “ v Bets s. ia he tye 9 eri hr, * s $8 , a t ‘ So Boe _ V5 ay Bat ‘ 
pee : " f bain a fe } tag e i. ny hiss 3 e 4 “ae nat 2% uke os decks as Ms bray reise “if = rth a SOS 
' ‘ ’ c LS y mM ah ea 28 i Ge CE anh Per Fe ur DN Pago Hoe 3 be o Ht Tae - Bish ia: oe ats 
43 : ; ve it ‘hk hs Yee a td a AA anee? te seit Ay Bala! . vias 3 ae by habe “ aeHt eo 
‘ 4 a : ‘5, a Ue Ad rie i of ibe sft) a ae Dit Sdait rf ry 7% whe a ay 
t é z 5 ¢ j ie s Rk oat F % ouest Ra or cate | = 3S eat | “a LSet 7 ns pty Cilis < 15 het 
' » 4 ‘ ' ; d i e ®r at Phat Cee! aa AS va ~ aes me oy ey 
a ‘ Pi AP] ' tae 1 ; a a neh ay voye att BS 3 T| ae e bed hz! nei. ‘ ve , ell os £,, 
1 ' e 2 . uu site ’ ? RK 4 oF ae § ish A ee Y My Rigk Ba ee CS am ate at oe ie A LP i e ode Barons yo 
‘ ' © : ny Crimi Stee 6 fideo ee a ak sale BH tee ae caren 
: . "Ge abe s ' qe pat x Taal 4 Vea! Fab 1g $ Me m5 Ki *8¢ 3 3 are ssw uae am 3 Ey hg ; 
' " B ¥ ie “FF j mes han eh Hs oe. a aly i ot Oe tant ~gishes aye 8 Mes, i; Sis. ks ten 
je : a, py ae RS Mt eat es Abana thal tho sige Reid ie sitet | 
a “a Wat bea a Baeltein, SAK Me Read thdgindgt biceoeis pec reas hy 
. 1 ' y y 2 1 1g \ t E et £ yA’) $Y if Siete \? athia 4] fata! oe hak ire) ta ie 
: ! : + on ' - mi. ‘Ss, : i aA ys agi a a oe f ein ee at at es ra 4.4 wh d be 
. A 4 ' Ez ! ae “a Nie at oe, Bie any Bye S303 3: t ep Fat Ry a 685 ‘i 
i 1 ae i e * 1 ue pasts ® 1 7 LAD rs t 7 ins y 
Pee ; oes “See BS aint Risa ry nae te tel aa rice 
sa tein z 1 F 3 . 7%, "i * ; ’ beat ~ F ! ty gr 3 tars a 
A ve en i id t ' fy coal my vane toe LRM oy t + SRE oes 5 £¢ Us Ay “a 
a mo sue te hte co babi ) ‘ leat pels iy Wiss e" ¥ ea fy ‘Five ; 
1a adie. ¥ i ie 7. ir os ity ts if; Aree ~Y 4 r ' ee eure ap +14 
, | : 7). Ben fice ais bret deh bl 
aoe i "1 ue : me . y ie the ager se “hy elit nda wo iy ar 5 f3 1 
A - * i 1S ' : Y Dri taey > 24 or Egy 1. ‘ 
: i , e ‘ : i . «8 - . ’ [oe sit sires: hal for ey, AY ied eis 4 
t ' », ae " male st ~4 eqs it emer Shays % 
ee ?, r , 'y 1 4 { x 4 - fos $%» ¢ +. fi m nf a oils, a ry 
‘ " ' - “toa ft ig ds 5, ie i. ! ses, 2 =* 3 : 
' 1 ite eee ist fay ® $ 
; ; ‘ ' . a 1 ' ' f ao" a a a ‘ te aes 
' A Le is seca Es ter r ee et 
erry : ca i “oe tee on : de A ao if 
or . a i i al in { Sut “1 *y? Heart S] ‘ hs i ig ae he 
® = I : 4)" , a} eS aa Tee yi aus a - 
oo of F) " bh ‘ eo i {> 4 i atlas y to Sissy tno 
: = +: a i “pos — Py . i Wee nitty ni ite Thyucht : re Peery see tte 
p ” wy . oo -? fl rh, ae Fey Na vit 
A at 5° £ :. ' 3 " a] 1 , ' ce Fi 4 ] ti As x ’ Mii ont ii ee agate Heats ive ve it wie As, ay 
f : ae € is oft. I i 1 , Se ! q B «* pee re iat ne " 4 eos io ars age i es 
i be. ' i : ; ia i my ite sas * 2M ep het “Fi, aris ay] oe pe wear 
‘ . J 1 a : uv Pray at al ah 10 whe af Fie re Lan ‘e2 wy 
' P he oan "s \ : tis «© Pare Tay Mike “ ; oe 1 ath Sa +H ee 
' ‘ ; ' . ake aT eae ¥ "Fl wasting eas egts a ae Se 5 pb Sy hy " 3° 
' TY u , at : Pa $ if : Sas . * 4 
‘n . ss ‘ " at ; uae ral Be 44) re eae See be ite Ri ts 
4 Mest ii ne a. | if tpg “aha lg ae : uM! , iy ie ee 1 hha . 
- , ; Q . 4 Mi | ge gté “f! yh: : a ‘t Ay = tif per; “ef A begeet if ae sect ada me, 
q a F 1 i ae ro A; aera / fis ed: ise oe wt sy fat 4g fate nas iN ot Aes Rae eae 
sone , ag Saas . ae ies *, ut “A hs $ « xt “ t ed, Pitt, tht vi HY ad va id ee neue pa = ; spe ark on, 
F ry . ey ay a Lie. tn % oe i! ave ny 1 ge 4 eo ee 3 he 4h te aa fer. v4 £3 F- 
4 e a ' “ v 4 *heae abe *.f S4en se 1 stay seit u 2 + i; $2 f a % 
* ay e * : - 
m4 ose et : } a fi, ec: ji *s areas , ge a nt 4 Beth if ats eet Og Lait ee Reuee Ht 1 fet “ ee 
' e ag: eee ee 7 e yes > Wi.s ~_t leak 
' , ' a ‘ é if = Rel . US of ba te, aN " M6, on fan ta i o a ps f 4 ae; ak Sat ti 3 re Ne , pee; ee 
t a vt ose | <*>. eae oda ates a é LT Z a Le alc sd rae F Pred ia s Ee ae feel ¢ fe 
J ' # i " ' us 4 Aloe 2 wii cae, x Pe an. : Pela a eer . : a, yg nee ts ail I ve tiat : asi onpdenye 7 spat i a 4] BEES = a 
a maar ” = ; er : « : : ol Na ajar : . re ¢ Gre" . 
' pu : is, Li ‘ i yea t ae | ate whey a fe a, teas 4 ie. i Pyie & Ff whee af ew oT, od ay) ait: Ae ‘ 5 My vf ee pil br 
i . a aot seis ’ Sabie ey) thot ey "f 4! ad orn baal} - eae eae Ain ie ~ . ‘ ag r PAY gh F 
es en PA sae. hee Cash eit’ re: ihe sites Ge iat ate SOL 7 f Sethe oS a al 
r ' t 1 a ‘ . - - 5 $- nay mk uae ig eae’ 1a £ H Lay ne hy . vaste sit 5 5 “ 3 at sl vet - use dhs . 
is pO pone an! a La sgeeeeitgenees : vty bes Betty fee attest hs nd, {4a 
- - ee 1 Reg ‘a i ta - R * tn vee Ls ’ 2 ‘Oates Ne ea: nie oor’: a te 1 “ak ? 4 ais oe nei iy 
a ey Wa Leet an 6 i A al ite J thak.e $6 Rest Jee, ny Yr, tos Ve : . A eatery A 
one ; ms 234 ry ee ; ate nate - eos +t nls rr F ety Naigt qe Lite ‘a ml ies +n hh ‘° gh ea 28 1 “hee ene 
oa * : . s ~ - toe "” ; a ' Ae “42 Se . 5 4 as ve ibe tptiels irae a ie ste :! oo by ane : a Nort ino oe 
a” , > , Dery a i ils ieee: Sat Ce ey bao “toby St Vin ra] ut “pen “iy eee cease { 4 wine A ieee he ¢ Her ae ve Atos gong cee ieee ahgae rf « 
, i. ? yet ae aid aaa te. Ss ariiat : ‘ito; eh | bid bet 1 Ae ae g “bts oA yi ebeesieegee : ca Ue ee és Tae as ue oa ores tots 
a 0 ta Mes Ne Mate for a 8 ae At vas as aE peiaeney Rear mer are ie teas : : 
‘ > ee cars i roar : 4 eee Pare +7) BAS D ay Narre te ayia ae H , 2528 Uk ral i 
TGs ate oe Wee ' Se ah, pipe osu oe santtlie re My LS ae att aie mites Pat en vague AAntess Cente 
‘ % Jn 1% bi as a i . + aH seh ze 3 Say ey Wg ¥ . = cd re. wut feu & at uh 7 sees! real te ioe 
Si @ Pec "a Sa Me ad Oe esr fait nhs te tit rier bat ake” i ans, pe Os 
A i 4 a by oe Ci Py a ae ~ ah t * wo ae t, au Le) ite aor iy : eye rate ote A a hay : ear oth fad ic eG ee yi bars ate a 
ol “y - Es ' a Ory ae Se ’ A 1, & % "Ss; regs ee ‘ Bs mga hy tk NEY alas Jat, hee 206 oe ‘oop se « pares fie 4 Ld ay L "4 sate i if 
c f 4 : te rae 198 iy wet Ge : AM HY Sus os EM ele Piya 
F 4 , am ,, ra i he as: ‘se 4, A BE es Naat Pay A M4 ith, t aor x: Ne RY : iar oe KR ORHE fie: ieee. wees tytn: ite a The wr Le f . : 
I aa 3 ee ook = rane cae 1) mic 8 +r 8 . nM ia ee ar 4 of ex eddy tools 5 o ian re oo LE I! make i we “ar ton ime a ase Seopig! = ade 
' ~ . iy Lr Me 4 a 7 eet? J rm te LO 1M »' Sie sl ie ye Lan 4 73 bd eee is ye + % Sie? s bebe ais ries g 208 ae a aed eae oe deny oe, atiny ven nae noe Lg 
fs ai acre ae tet, se a ate Daa ie Edie Dy.4 igri ae “ad tele pie id “i : Sees ee iat ane erent 
; ase a? CG 1 A ae 1 a eee 1 Ut Ll “y eet . Be Lic: of, 1% ‘ Mts ‘ ogee oFesas ae bad hid Be le - i t. 1 et 
ts a F cee ; on Be ie Perera ue wpe Ge dist Gis Mf Me. “Ne ie gf mate ane eh i Y aa vier: dans “45° i Sa A aa 
ee 4s ri e ie a EO) 1 etou 7 Js es ayy! 1 Inte Aas a raed | « ier Jf pe wth dest & Gy) rene ie ted eee ah Tete giro rer re my 
" oe hae Came. iat ee a “A sicily ‘tet een ee ypu eoe ate ee eee bar tess as mse ve ons eee nae = feet 
ee ' “ ms 4.) vas Sa Bac wig re petty igayt te yee ‘ rig fae yah: Bits vee ste ” Fy tet it oe gaete visti! i Wenge 
ie a 1? eee ‘ Pee an ix wah Ltd eye oy ot’ fetes a att ik os mite ar oh fis pena jiadoka Pauw aha aye ae a sttyey tats aseetas Hie it ve po : = 
S 4 U gui ‘ Lie ba J 8 pt ¥ Jus *. L! rae Perc bai Py l vos wer te . fae ‘o 35 Me ofiave Mais peat range 
Avail ‘ae “tic F ary plat) IR) MC con - ° ‘he aul 1 Miss" we ee Pe OS gtk: mth a tA Ea oad Hiatt he ae ie td Be) ite Petia yaad arte ieee 
; Lal "A oe are h ny 5 is :, * gael . 1 ounce , ' Tey eyes as ee eye ee toe « giiees bandue pater eae . + acy el ' 
wen ae Su : i srg + ake. ae *; “ah e ’ bard] 4 : Magi oe ue ee blir i atv cre Ker fe nttie Gd arent ar yy atte 1 hind bie “ 4, 
! ake § 1% r Ses 7 ore bs ee ia: “a. i aan : % yi if aie of eee ire J a rj itd Pan $ iether, eg ht Dede Faas mys aja. PS suey sites ae nfs 
A ' ES bers 5 ew are Ste 4, 8 a 9 sol} ramets 7 ¥6e4) 4 i ohare vies Pay js ete rigtoesi te itacs eles eH pdr repre sh Payie 
, , oe in : pie H 9. 2 1 a Eee + wy ” | ea PhS “aby im fi" 7 pats oy i hate ot are 7a sane) fer a | Waive 
ae ar - 3, falai "1 “ay 4 ry nt te ae 33 feat “we liz Lt of Byte “i6 #80 § sosyet aa 2, eee! A ay .e : ramnagene 
rn 4 4 ‘Pes a y “et Hi 9 ae is ery aes W =o, Le oye gin $i ‘ Webs ea, * tbe ls pe iat sey 6 ira} ip 
i. f{ oe bets & Mr mee Oa ai : thes es ato, it r cee 3° ins HW nea Na mata a wes tis nh “i anaes ee eee eel 
a ’ eee HY * ite Lae “ bt + gre Od ar) Aye " ca skh ease ey al atraiaigese eae ay ore eat be * Y 
te } ' By y. fe ‘ mai 5 9 tes ath iis jee A me whe 3 1g Cie ee vi +0 a2 af ive gee Liek beh reas ues ees “i 
bes eee dh | hg NG Be las Tate wipes Doe aver a Hetil hy ip seh retin rent aera ‘ 
i, 7 : i ee Lid intts 5: H ay “The at aie ghee 19 4305 Bock it hake ee va 2 yin aft oe ae aes rat pit ne ene 
P+, . ; s ae Fatah te pre a s? 7 eld ray, ry 
zl 2 ‘Ve | ana y ar noon ¢ Sie: Bet! Rat x iets ees. Se sitet) > fe wis 16 ae oe Ana 
a > oS , a ibe. oa ae ter. A : Aintg +n ERs aot ur e Bits i. 849,6 sh we ee ty ba ik eit babs 0 
a oN, t, n ooh ah ee " a fit at iy 7: . Eke ve seats 5% shes ha ae aig Spates cistet Hig? cathe Ha ah ‘pi wet: By seal 
' “ae s e 3 vt aes whe ibys ee 78; vit Ae > is i ’ S¥ mS raat iy i “" iat the lyse ptsay ae mi aa 
, a beet Ng ee iG er Tish ihe rat i Fens: tat ne, % Lattin fate inehh cnt H Nit oaks A oe 
ae - 1 i. stb ag ait, a) ic " ret ais iv OU aH pecteylets M68 he th Vehetee cthedl Beles (haven or bac nites isk 583 ike esosll 
vib * i¢ "ht ona Foe yy a Be ‘2 nefits sees en sees ated we wit) ab 40H, ty aeh Peak A ay bist ite “eevee eras en 
a : a s n Ag eaaeaes Sire vis ne ont " tay Fite ad ete bavees SPA. ttt yee om a “ ahiet Pes finss) va 
baztct | one pen ail saat va By hy abe ieee: G 
“SEO AR Man ‘hace ee pet Benet ea earn eae site fii Hae res stat 
R a's H “tat Fone san 4 Seyi i rm if an Hedy) as " “ Be OF . Coat at iseyts aves tg hye % ee at tt 
ete ieee staat atte! re yj Atl tet ite y ert ts Stn Bree fe ai; pee ey taki tek aS | 214 segs erat a faa 
4 eaf, . ' Seas i. $a hare xt ea pir tte) ° ie og 
i See i ne a ke 4 tay a fe, petiole ove Bee ai yy Be wi es peta ie ty * aie iaatich 
4 a a ees “ f - x * 7 rik Eig ao ' 4 oy ? ¥ 1 iSeaiernnce 
; ee 1 6 ey aes se aig pen ees nt Aer hg nae ; ue ae ‘s sine # My, Hh be sie pate eae 
: Sr. ae ! i) ae "n tr OF he Pry Lisgad +i vied aig "Tee Sw ptae) a hie agubas . ‘behets apes re ace 
, ' ae ’ De $ a ee {. ’ aly he fs e tds sy bSus 9 ha NH ae piano tue Br wats vy ae jhe cane = ah Pp etaites Sie atotyt 
t a ‘ .5 : ae ‘ EPR a , ; t. . “oie tes ns ~, cont h Bh ad pe a Pea 
‘, ee a er te apa Mea a Seta arse tape ie Tabi tt See te eanes putes ' y bish ie 
alae we iy sige: in peas ie Bier glial heater path aR ae | a 
oe . e Wy Wika i 8 . i rae a. vee . 3 r4 "5 t , . 
. = a ie a ate aie Sa soya oe gl tg et “Vatied St old trees ny ARE 
2 ; Pe ee rn i (b= % MH ae i nt 4 ia » . dy ret 1 aM Pn, ties ag fe 
- 5 ‘ AP “ 13 a ys au \ ul Py ie - 2 Ald “i co ; ‘ete sees 4 Sabie "lad a 4 4 {? 
= me 4 e ‘ eee Us B vt ae ie 5 . “ eet Fig con Taste an act tas ea Sm : : ’ aad 
A nn out a de a : oat pate iy oa i a eon ie ey I ih ayetio Hi he at ae Ae 
% ' mS ate . 4 f t =! ay ee ie Be ins “x ’ * ri : paved Aaah 4 tb Pe ot, : nA 
' ‘ | “age eee ae “ " " 4 a ia ‘= ieee mine ar! itt pa he 
‘ : ao f : le ou 3S el 
hs a ee rie “eh We eee 
; 8 Ute rf : i Ah wh | hata x ay! *e 6 t 4he te ig Py 
‘ a a A ' 48 . ae i 3 ia A, t K. . seAae , si) i] AK wie 2 5 
e . 1 : ‘ La wees] 7 5 . 7 
ti a op + en rhe e wate Bhi he 
t é Us * 7 
4 ¢ on a ay 1 ’ a4) I etre r ¥ : 1a} Bitgne J “4 
1 Ms ih Ad {: = ‘e ‘ , 7 oe ; Git, ¢ te : x th Pet site 1 f 
; “thy s 33 fs ‘ af - ; ea ‘ A ° + m : il "ibees ars ate LPs es 
‘ | tre Pitas . “t : t, J Pe iat Sy 2 t me pe at tar ry ig: aay Ah 
mos : obs ‘ae! us Mal psf hn a4 esr? Pi a, sichaly ae heed : 
. a ae. " i 4 ry - ae @s Ay tS 4d) i y aL adres 
aaa : ao eye 4 “aut us ye 7 ¢ bab Ph isd} 
“nn ' ¥ ‘ : ey y ; 
a , e vy fei ye 2 ay id ' Mana Si s} 
. ry ". ra Ue ‘3 % 2 fe. ai € f the) ; us 
: ' ' Paar . i iN ‘e p. Pra To A 
i ye iad siete ‘ 
3 . : &, , 
1‘ 
 . ' i . 
t ' 1 ? i 
i i ‘ 
1 bi ‘4 
t 
s ‘ 
¢ I . e t 
. ¥ id 9 he 5 
jw 











NAVAL POSTGRADUATE SCHOOL 


Monterey, California 





THESIS 


DESIGN, IMPLEMENTATION AND EVALUATION 
OF AN OPERATING SYSTEM 
FOR A NETWORK OF TRANSPUTERS 
by 


Mauricio de Menezes Cordeiro 


June 1987 


Thesis Advisor -Uno R. Kodres 





Approved for public release; distribution is unlimited. 


— 





UNCLASSIFIED 
SECURITY CLASSIFICATION OF THIS PAGE 


REPORT DOCUMENTATION PAGE 


ta REPORT SECURITY CLASSIFICATION lB RESTRICTIVE MARKINGS 


da SECURITY CLASSIFICATION AUTHORITY 3} DISTRIBUTION / AVAILABILITY OF REPORT 
Approved for public release; 
Distribution is unlimited. 









(20 DECLASSIFICATION / OOWNGRADING SCHEDULE 


4 PERFORMING ORGANIZATION REPORT NUMBER(S) |S MONITORING ORGANIZATION REPORT NUMBER(S) 








6a NAME OF PERFORMING ORGANIZATION [6b OFFICE SYMBOL | 7a NAME OF MONITORING ORGANIZATION 
(if applicadie) 
Naval Postgraduate School a Naval Postgraduate School 
6 ADDRESS (City. State, and 2iP Code) [7b ADDRESS (City, State, and ZIP Code) 
Monterey, California 93943-5000 Monterey, California 93943-5000 


8b OFFICE SYMBOL 9 PROCUREMENT INSTRUMENT IOEN TIFICATION MUMBER 
(if applicable) 


Ba NAME OF FUNDING SPONSORING 
ORGANIZATION 








Bc ADDRESS (City. State, and ZIP Code) 10 SOURCE OF FUNDING NUMBERS 


| PROGRAM | PROJECT TASK WORK UNIT 
ELEMENT NO NO NO ACCESSION NO 


1) TILE {include Security Classification) = DecTCN, IMPLEMENTATION AND EVALUATION OF AN OPERATING 
SYSTEM FOR A NETWORK OF TRANSPUTERS 


r2 PERSONAL AUTHOR(S) 


CORDEIRO, MAURICIO DE MENEZES 


Ja Tyee OF REPORT ‘3p TIME COVERED 14 DATE OF REPORT (Year, Month Day) {15 PAGE COUNT - 
Master's Thesis FROM | June 1987 163 


"6 SUPPLEMENTARY NOTATION 











" COSAT! CODES 
£0 sua. GROUP 


"9 EZBSTRACT (Continue on reverse if necessary and identity by block number) 


18 SUBJECT TERFAS (Continue on reverse if necessary and identify by block number) 
Transputer,Operating System, OCCAM, TDS, etwork, 

Concurrent Processing, Distributed System, Routing, 
Message Communications 







This thesis presents the Design, Implementation and Evaluation of an Operating 
System for a Network of Transputers, with main focus on the Communication 
Subsystem. It also introduces the novice to the Transputer Development Systcm 
(TDS), and suggests a sequence for developing applications. 

All the programs and examples presented in this thesis were implemented in the 
OCCAMI Programming Language, and using the Transputer Development System 
(TDS-D600), running under the VAX/VMS Operating System at the Naval 
Postgraduate School (NPS). 





660 OS RBUTION/ AVAILABILITY OF ABSTRACT 21 ABSTRACT SECURITY CLASSIFICATION 

CY) ONCLASSUIEO/UNLIMITEO (7 SAME AS RPT C) oric USERS UNCLASSIFIED 
eee ONSIBLE INDIVIDUAL 22b TELEPHONE (Include Area Code) | 22¢ OFFICE SYMBOL paneer 
A Prof. KODRES, UNO R. (408) 646-2197 Code 52Kr 
JO FORM 1473, 84 mar 83 APR edition may be used until exhausted SECURITY CLASSIFICATION OF Tri§ PAGE 


Allotner editions are obsolete 


1 


Approved for public release; distribution is unlimited. 


Design, Implementation and Evaluation 
of an Operating System 
for a Network of Transputers 


by 


Mauricio de Menezes Cordeiro 
Lieutenant, Brazilian Navy 
B.S., Brazilian Naval Academy, 1976 


Submitted in partial fulfillment of the 
requirements for the degree of 


MASTER OF SCIENCE IN COMPUTER SCIEN GE 
from the 


NAVAL POSTGRADUATE SCHOOL 
June 1987 


ABSTRACT 


This thesis presents the Design, Implementation and Evaluation of an Operating 
System for a Network of Transputers, with main focus on the Communication 
Subsystem. It also introduces the novice to the Transputer Development System 
(TDS), and suggests a sequence for developing applications. 

All the programs and examples presented in this thesis were implemented in the 
OCCAMI] Programming Language, and using the Transputer Development System 
(TDS-D600), running under the VAX/VMS Operating System at the Naval 
Postgraduate School (NPS). 
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I. INTRODUCTION 


A. BACKGROUND 
1. The AEGIS Project 

The research interests of the NPS AEGIS project embraces a broad spectrum 
of topical areas within the Computer Science Department. Initially found in the late 
1970’s 1t had the primary mission of investigating alternative architectures for the 
AEGIS Combat System, which are being deployed on board of the U.S. Ticonderoga 
class (CG-47), whose central unit is the 3D Phased Array Radar AN/SPY-1A. 

The basic thrust of this research is the belief that the same software svstem 
running under the old and expensives AN/UYK-7 computers could run equally well. if 
not more efficiently, in the commercially available VLSI microprocessors. 

A sequence of projects have culminated in the successful Real Time Cluster 
Star Architecture (RTC ). 

The RTC is a multiple microprocessor system with a hierarchical bus 
Structure resembling the Carnegie Mellon Cm’ architecture. RTC is specifically 
‘ suited for the development and implementation of real time, concurrent sensor data 
gathering, display and control systems, which are some of the typical applications in a 
Weapons System [Ref. 1]. 

Presently, the RTC is composed of two clusters, each containing four INTEL 
Single Board Computers based on the 8086 microprocessor. These single boards have 
from 64K up to 128Kbytes of dual port dvnamic RAM being shared among each 
cluster, with part of this memory space being virtually shared between clusters. All the 
boards are connected to the INTEL Multibus through an interface control logic unit 
and the communication between clusters is done via an ETHERNET link. . 

The software svstem to support the RTC was done in parallel with the 
hardware design and after six vears of iterative engineering, refinement and extensions. 
it evolved to the E-MCORTEX operating system, which was integrated in 1984 as a 
system software layer over the multiuser CP/M 86 operating system [Ref. 2: p. 10]. 

As time progresses, the old AN/UYK-7’s in the AEGIS system are being 
replaced by the new AN/UYK-43’s, and as expected, in probablv less than one decade 
they will not be capable of handling the increasing demand for some more complex 
software systems. 
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That is why the NPS AEGIS Modeling Project, trying to keep up with all the 
upcoming new technologies, has added to its Laboratory a network of eighteen 
transputers, which can be very easily connected in various configurations, to allow the 
user to evaluate and compare them, in a performance basis with the RTGs 
architecture. 

2. Transputer Review 

The term transputer is an acronym for “transistor computer” where it reflects 
the ability of this device to be used as system’s building block, much like the transistor 
was in the past. The nice feature of the transputer is that it adds a new level of 
abstraction, which provides a very simple way to design concurrent systems. 

As a formal definitron we could state that a transputer is a single chip 
microcomputer with its local memory and with four independent links for connecting 
one transputer to another. The links may be thought of as small special purpose 
processors which steal no cycles from the main cpu, in such a way that we could have 
all four links and the cpu working at the same time, without degrading the performance 
of the program’s execution [Ref. 3]. 

The interprocess communications are done through channels, using a strictly 
message passage schema where shared memory 1s not allowed. Each link provides two 
channels, one in each direction. A message is transmitted as a sequence of bytes and 
the way the transputers know when the other transputer is ready to receive a message 
is as follows: the first transputer to become ready transmits the first byte of the 
message and once it arrives in the other end, it is stored in the buffer of that link, and 
just when that link is ready to receive the next byte an acknowledge signal is sent back. 
Each of the links must maintain a buffer of one byte long for this purpose. 

The communications between links is bytewise asynchronous and not phase 
sensitive, but it is, obviously, bitwise synchronous, otherwise we could not sample the 
bits correctly. 

a. The processsor and its scheduler 

The transputer, IMS T414, is a general purpose 32 bit microprocessor with 
a maximum throughput of 10 MIPS.! It is highly optimized to implement the OCCAM 
Programming Language and it has a reduced instruction set, where many of the 


instructions are one byte long. 


‘Tt depends on the type of the transputer, more specifically on the internal clock 
under which it is running. The following values apply: T414-12 (6 MIPS), T414-15 (7.5 
MIPS) and T414-20 (10 MIPS). 
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The processor supports two priority levels, high and low, and for each of 
them it keeps a queue of ready processes. The low priority processes will run only when 
there are no high priority processes in the queue. 

The OCCAM parallel construct is implemented on a single transputer, by 
timeslicing the processes which are ready at any instant in time. A process 1s 
descheduled if it has to wait for communications, timer input or if it completes 
processing. Another possibility for descheduling, valid only for low priority processes 1s 
when its timeslice is finished, so that the next in the queue will be activated. Each 
timeslice period lasts for approximately 800 microseconds. 

b. The [414 Timer 

The resolution of the timer depends on which board we are talking about. 
On the BOO! the timer has a resolution of 1.6 microseconds per tick, while in the B0O3 
we have | microsecond for the high priority processes and 64 microseconds for the low 
priority ones. If working with the VAX-VMS the timer ticks every 100 nanoseconds, 
but it 1s updated just every 10 milliseconds. 

The value obtained from the timer is a signed integer which wraps around 
at MAXINT (27! - 1 = 2147483647) and MININT (- 27! = -2147483648), so that 


Bi 


attention is needed when trying to subtract times.~ See Figure 1.1 for a summary. 


Resolution Half-Cycle 
usec/tick S72 mn 


BOO] : 
BO03 .O usec/tick Sen cumin 
B003 pUmusec, tick 38.2 hrs 
.O nsec/tick See min 





Figure 1.1 1414 and OPS Timers. 


c. Memory 
The [414 can directly access a linear address space of up to 4 Gbvtes. The 
32 bit wide memory interface uses multiplexed data and address lines and provides a 


data rate of up to 25 MBytes/sec. 


2 routine called tick.to.time will be provided in the O.S. Library Routines, such 
that all the cases will be handled properly. 
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There is 2Kbytes of on chip memory which provides a maximum data rate 
of 80 Mbytes/sec and can be shared among different users through the internal system 
bus. The latter value is obtained when using a memory with access time of 50 
nanoseconds, but it also varies from transputer to transputer. 

The address space of the T414 is signed and byte addressed. It ranges from 
#80000000 which is equivalent to MININT, up to #7FFFFFFF which is MAXINT. 
The first 2K of memory, in other words, from #80000000 up to #80000800 reference on 


chip memory, where the first 72 bytes are reserved for system purposes. See Figure 1.2. 


7FFFFFFF TOP OF MEMORY 
7FFFFFFE BOOTSTRAP FROM ROM 


PERIPHERAL BASE ADOR. 


TOP ON CHIP MEMORY 


WEM START 


SYSTEM MEMORY 


LINKOin 


= 2 * = = ©: XX * 





Figure 1.2 [414 Memory Space. 


d. Links 

The T414 has four full duplex standard links, each providing two 
unidirectional channels. The links can be thought of, as described earlier, as a special 
purpose processor which has some DMA block transfer capabilities. 

The speeds of the links may be selectable from 10 Mbits/sec or 20 
Mbits/sec on the BOO3 boards, with no choice cther than the standard 10 Mbits/sec on 
the BOO! board. The BO0O3 board has the additional capability of maintaining link 0 at 
10 Mbits/sec while the remaining links |, 2 and 3 are at 20 Mbits. Therefore, care 
must be taken to enforce that both links connecting the BOO! and the BOO3 board are 
working at the same speed, 10 Mbits/sec. 

3. The Transputers at NPS 

As far as hardware goes, we have in our Lab a Transputer Evaluation Module 
with four boards BO03’s, each containing four 32 bit transputers T414-15 (15 MHz) 
plus 256Kbytes of dynamic RAM per transputer. The fifth board we have 1s the B00] 
with a 32 bit transputer T414-12 (12.5 MHz), 64K of dynamic RAM and 128Kbvtes of 
EPROM containing the bootstrap loader, the memory test and the transparent mode 
software. This board 1s directly connected to the host computer (VAX/VMS in our 
case) through a RS-232 serial port and it also provides an additional port for attaching 
one monitor. . 

We also have another board which is the B004, which is placed 1n one of the 
slots of a personal computer Zenith 248. This B004 board contains a 32 bit transputer 
T414-15 (15 MHz) and comes with 2Mbytes of dynamic RAM on board. Its basic 
function is to provide an interface between the PC and the network of transputers, but 
it also allows us to run programs in its transputer, much likely the BOOI. For additional 
information about all the above mentioned boards, please refer to their respective 
user's manual [Refs. 4,5,6]. 

It 1s important to notice that the BO03 board does not allow one to have 
access to the links 2 and 3 of any of its transputers. They come in 4 fixed configuration 
(see Figure 1.3), where the only links the user can connect however he desires are the 
links 0 and I. 

At present we have three software packages on which we can either simulate 
or actually generate code for the transputer. They are: 


¢ OCCAM Progamming System (OPS) which runs under the VAX/VMS 
Operating System and allows one to simulate the transputer environment, using 
the OCCAMI as the primary language. The code generated by the OPS 
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Figure 1.3 BOOQ3 board and its fixed connectivity. 


compiler is for the VAX/VMS, so that no valid time measurements can be 
made, nor can we run truly multiprocessor programs. As it stands right now it 
1S Just a very good tool for teaching purposes, since it allows many users to run 
and test their programs, concurrently. Another use of the OPS would be in the 
early stages of the design, for checking the correctness of some modules, before 
running them on the transputer itself: 


e Transputer Development System (TDS-D600) which also runs under the 

_VAX/VMS Operating System, and whose compiler generates transputer code 

which can be later on extracted and downloaded into a transputer network. One 

of its differences from the OPS is the configuration part, where a program can 

be configured to run in various processors, Which are connected in some 
specified way. The primary language 1s still OCCAML. 


e Transputer Development System (TDS-D701!) which is very similar to the D600, 
although more powerful, and it runs on an IMS B004 board in collaboration 
with a small program running under the DOS Operating System in a personal 
computer, which provides access to the PC’s resources. [ts primarv language 1s 
OCCAM?2 which has data types, floating point arithmetic, among many other 
things that are not provided in OCCAM 1. 


B. VPURPOSE OF THIS THESIS 
Since this is one of the first thesis to make use of the transputer hardware,® our 


mission was to create a user friendly environment, with all the software necessary for 


future users to develop their application programs. 


3We had two previous thesis on transputers, but they were actually designed to 
run under the OPS in the VAX, since we had no transputers at the time they were 
written [Refs. 7,8]. 
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The tools we are about to describe embraces a library with all the basic I/O 
routines, such as output to the screen, input from the keyboard, capability of 
formatting the screen and to write and read from VMS files among others. Also we 
have developed some utility routines which will allow anyone to dump parts of memory 
and to get the real time in a readable format anywhere in the program. 

However, the central focus of this thesis is on the design and implementation of a 
basic Communications Operating System, which would make it easier to program a 
distributed network of transputers. All the effort was made to carry out this task and 
after many, many changes, we ended up in a very simple and effective design. We are 
not claiming that this is the onlv one or the best way of doing it, but it 1s our hope 
that it serves as a firm foundation for future and more enhanced implementations. 

We also evaluate what is the overhead imposed in the program’s execution time, 
when running under the Operating System, which constitutes one of the most 
important concerns when dealing with real time systems. 

Unfortunately, when this thesis was started we didn’t have the OCCAM?2 version 
available to use as our primary language, which would have made life much easier. As 
a result we are using PROTO OCCAM or OCCAMI throughout the entire thesis, 
which is a very simple but primitive language, with no data types, no channel 
protocols, no floating point arithmetic, etc.... | 

As an auxiliary learning tool we will provide for the novice user of the 
Transputer Development System for the VAX/VMS, a quick explanation of all its 
features, its required program structure, its drawbacks and all the points we found 
obscure in the manuals, whose knowledge would have saved us a lot of hours of 


reading. 


C. THESIS ORGANIZATION 

Chapter II begins with a brief overview of the Transputer Development System, 
in order to assist the reader in understanding its basic features. Next, we suggest a 
sequence for developing applications, where we present a very thorough description of 
all the steps involved. Still in this Chapter, we develop a very simple methodology for 
configuring a network of transputers. The remainder of Chapter II is devoted to some 
general suggestions, in order to make the working environment, as friendly as possible. 

Chapter III describes all major design decisions we had to make, in order to 


implement the Operating System. The main purpose in doing that, is to provide the 
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reader with a precise conceptual understanding of the system, which would enable him 
to perform some major changes in the system, if it is so needed. It also presents a 
general block diagram of the Operating System. 

Chapter IV describes the implementation of the modules in the Operating 
System. The Library Routines are also covered, mainly the “send” and “receive” 
routines. A complete guide explaining how to use the routing table is also addressed. 

Chapter V evaluates the performance of a program running under the operating 
system. All the evaluation is done in a comparison basis with the one made by Vanni 
J.F. in his thesis [Ref. 9], where the transputer is completely evaluated. In this Chapter, 
we also perform the evaluation of the operating system, when handling multiple hop 
communications. At the end of Chapter V, we measure the effect of the header size on 
the transfer rates. 

Chapter VI basically describes how to use the Operating System, under the user's 
point of view. The required program structure 1s also presented, as well as some hints 
in how to program with the operating system. 

Chapter VII is the final chapter, which includes the conclusions and some 
suggestions for follow-on work. 

Appendices A and B includes the global definitions to be used in either OPS or 
TDS 

Appendix C contains the file LIBRARY.TDS, with ail the available routines to 
be used in TDS, without using the operating system. 

Appendix D contains the source code for the Operating System in the root 
transputer, while Appendix E contains the remote version of it, in other words, the one 
which is to be run in remote transputers. 

Appendix F describes the evaluation program used to evaluate the Operating 


System, and it also serves as a sample example on how to use the operating system. 
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Il. A QUICK TDS TUTORIAL 


A. WHAT IS TDS ? 

The name TDS stands for “Transputer Development System” and it is basically 
built around the concept of “folding”. 

Its fold editor 1s the principal interface between the system and the host 
computer. It allows the user to insert, edit and delete Occam source text, and to save 
this text into a VMS file. 

Besides its general and standard editing functions, it also contains a set of ten 
utilities and three special functions, which perform extended tasks with a TDS 
program. 

We will now cover the basics of its folding system, describing all the avaiable 
commands. We hope that by now the reader has already been exposed to the editor 
tutorial, where all the basics about “folds” is covered. It is also important to notice at 
this point, that this editor uses a very unusual sequence of keystrokes and therefore it 
is of primary importance to have the correct terminal driver running under it. We will 
assume hereafter that the system we are using is the TDS for the VAX and that our 
terminal 1s the VT-100 or VI-200 (in VT-100 mode), but if that is not the case, please 
refer to the TDS Installation Manual [Ref. 10: Section 1]. 
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Figure 2.1 DEC VT-100 Keyboard Layout. 
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Besides all the editing features common to all editors, the TDS has in addition 


what we call “utilities”, which are the following: 


Utility 1 (TRANSPUTER CHECK) - It checks the syntax of occam programs, 
as well as the consistency of variables and channels used inside PAR constructs. 
When dealing with more complex structures like for example nested PARs, 
etc...very often we will have to turn off the “UsageCheck” which is found inside 
its parameters fold, otherwise it will give us all sorts of error messages. 


Uulity 2 (TRANSPUTER COMPILE) - It compiles PROGRAMs and SCs 
PROCs or it may configure an Occam program to run in a network of 
transputers. In addition to the same checking performed by Utility 1, it also 
generates code for the transputer, placing it into a fold. Actually, it generates 
two folds: the descriptor and the code folds. It shares the same parameters fold 
with Utility 1. 


Utility 3 (MAKE PROGRAM) - It produces a compilation fold marked as a 
main program fold. It should be used only in the outer fold to specifv the whole 
program to be downloaded into the network. Typically we will have inside such 
a fold all the SC folds for each of the transputers being used by that program, 
plus the configuration fold which carries all the information regarding the 
connectivity of the network. 


Uulity 4 (MAKE SC PROC) - It produces a compilation fold marked for 
separated compilation. All the processes to be run in a specific transputer must 
be placed inside a SC, which will be eventually allocated to that transputer in 
the configuration part. : 


Utility 5 (DESCRIPTOR INFO) - Provides information about any SC fold. It 
uses the descriptor fold to get information such as entrypoint, program size, 
caer 


Utility 6 (EXTRACT TO FILE) - It extracts the compiled code that lies inside 
the “code fold” generated by the compiler and exports it to a VMS file. There ts 
one parameter fold which prompts the user to enter with a filename to which to 
export that code. The default filename 1s “ops.tcd”. 


UCulitv 7 (WIRING DIAGRAM) - This utility creates a fold with a textual 
description of all the link interconnections needed for the configuration specified 
in that program. This utility is, indeed, very helpful when setting up vour link 
connections. 


Utility 8 (SEARCH) - Searchs for a string from the actual cursor position up to 
the end of the fold on which it was applied. It doesn’t allow the use of any 
wildcard characters. 


Utility 9 (REPLACE) - Replaces the string we are searching for, by another 
string. It shares the same parameters fold with the searching utility. 


Utility 0 (LIST) - Produces a printable listing of the contents of a fold and 
places it into a VMS file. It prompts the user to enter with a filename. 


pape 


Besides the above utilities we have three more special functions which are: 


e Func h (HELP) - Displays a list of all ten utilities provided by the TDS, with a 
brief description. 


¢ Func f(FOLD INFO) - Displays the type of the fold and its contents. 


e Func s (SETUP) - Allows the user to change any of the parameters fold already 
instantiated with new values. 


Once we have gone through this brief description of what TDS 1s, we should now 
have the feeling that TDS is very closely related to its fold system. Unlikely other 
systems where we have a physically separated editor, compiler and linker, in the TDS 
we have all in one. Also another good point about this approach is that if you get an 
error while compiling you will be placed right at the error in editing mode, and once 
ready just call the right utility to compile it again ! . 

The way this editor handles external files is also very unique. What we have to 
do is just to open a fold, name it with the filename and extension of the file we want to 
be attached to this fold, press the file key PF3 and that 1s it. That is how it does the 
job of linking almost transparent to the user. 

Just for the sake of completeness, it is worth mentioning the system files which 
are used by the TDS: 

e TDSVT100.OBJ - Transputer Development System for VT-100 terminals. 
e TDSVI920.OBJ - Transputer Development System for the TVI-920 terminal. 


e TDSTABLE.OBJ - Transputer Development System with table-driven 
terminals. 


e OPSKRNL.OBJ - TDS Kernel which is identical to the OPS Kernel. 


e TDSSETUP.COM - It is a VMS command file which sets up the TDS 
environment. Must be executed in the beginning of everv session. 


B. STRUCTURE OF A TDS PROGRAM 

In this Section we will cover the basic structure of a TDS program when running 
without the Operating System, which will be covered in later Chapters. Any program 
intended to run under TDS, in other words, in a transputer network. must have a well 
defined structure, which doesn’t allow much freedom for changes (see Figure 2.2). 

ites basic idea is that for each different process to be run in a different 
transputer, we must make it a separately compiled unit. The number of parameters 
depends on how many hardware links are being used by that process, and also if any 


constants are coming as parameters from the configuration part. As we already know, 
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PROGRAM progname 
SC transputer.1 (CHAN A,B,C,D,E,F,G,H) 
PROC transputer.1 = 
lobal “de finmtrorna 
ibrary routines 
.. PROC terminal.driver 
«ee PROG User 1 
PAR 
terminal.driver 
user.1l: 


SC transputer.2 (CHAN A,B,C,D,E,F,G,H) 
PROC transputer.2 = 
lobal definitions 
ibrary routines 
os SE ROG Weeta 
SEQ 
user.2: 
°o 
0 
0 


SC transputer.n (GiAN Aye epee cep 
PROC transputer 1) — 
lobal definitions 
: lbrary routines 
wen PROG suser. 0 
spats, 
user.n: 


- configuration declarations 


PROCESSOR 1 
. Channel placements 
transputer.1 (...placed channels...) 
PROCESSOR Z 
.. channel placements 
transputer.2 (...placed channels...) 


0 
0 
0 


PROGESSOR on 
channel placements 
transputer.n (...placed channels...) 


Figure 2.2 Program’ Structure in) 2S >. 


the BOO3 board has some links which are hardwired, providing no access to them. 
These channels need not be placed in the configuration. 
Inside each SC we should create a fold with the most used definitions and 


declarations (see Appendix B). Similarly, the library fold (see Appendix C) should 
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contain some often needed routines such as I/O routines and other utilities. Our 
suggestion is that all useful routines should be included in this fold, as they are created. 
The approach we have taken is to make them filed folds in such a way that whenever 
you make a new program, all you have to do 1s create two new folds and attach those 
files to them. 


The sequence of steps to attach these files in our program is the following: 


1. Make sure you have these files in your working directory. 

2. Open a fold inside the program you are working on. 

3. Name this fold with the name of the file you want to attach. 

4. File this fold by pressing PF3 on the VT-100 terminal. 

5. If you have some limitation in memory or if you are not going to use all the 


routines and definitions that are in there, you should unfile those folds in order 
to not interfere with the original contents and proceed with the desired 
modifications. This step as we can see is an optional step and is just carried out 
for memory savings and readability purposes. 


As depicted in Figure 2.2, the third fold inside the SC PROC is the terminal 
driver, which is crucial if we are using screen outputs or keyboard inputs. It defines 
hardware memory locations which represent uart (universal asynchronous receiver- 
transmitter) registers, such as mode register, status register, command register, etc.... 
All of these are defined as offsets to the peripheral base address which is #80040000. 
Its basic functions are to reset the uart which we are going to work with,* and to 
define the baud rate for communications between the processor and the monitor. The 
first one is accomplished by the procedure reset.uart and since it takes a while for the 
uart to become ready, a built-in delay is provided inside this procedure. 

The terminal driver is always ready either to receive a character tvped at the 
keyboard or send something to the screen. If you check the code it 1s clear that both 
tasks are just performed after the uart receives a tx.ready or a rx.ready in the status 
register. Furthermore, if the uart does not receive either flag within 5.12 seconds, the 
uart is considered to have failed and the terminal driver is exited without further notice! 
The reason | am telling you this is because we had some intermittent problems in the 
very beginning of our research, which were very nastv to isolate, and ended up being a 


problem in the uart. 


4We have two uarts, the uart A is connected to the terminal and uart B to the 
host computer. 
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It is also worth mentioning that unlike OPS, where we must send the “end of 
buffer” ascii code at the end of the message we are going to output to the screen, in 
TDS we don’t have to. 

The terminal driver must be placed in PAR or PRI PAR with the user process in 
order to work properly. The choice of either one construct is not always clear, and it is 
intimately related with performance, but the unwary use of it may bring up subtle 
points when dealing with complex programs with nested PARs and PRI PARs, so that 
the suggested approach is to make your entire program with no PRI constructs and 
just after it has been proved correct, you should assign the priorities where needed. 

In the PROC so called “user.n”, we have a standard structure like any other 
programming language such as Pascal, PL/I, etc... where we have a declarations part, a 
bunch of procedures which may be nested at any level and finally the main body of our 
outer PROC user.n. The only main difference is that we should make the channel 
placements inside this procedure, attaching the software channels to the hardware links 
of the particular transputer, to which that process is going to be downloaded. Of 
course, these placements must be in accordance with the configuration. 

As one may notice we have put A, B, C, D, E, F, G and H as channel 
parameters for the SCs, but rather than calling them generically as we did, we could 
Just as well have put the actual channel’s names as parameters. In doing so, we 
wouldn't have to make their placements inside the PROC user.n, since they were going 


to be directly related to the order specified in the configuration. 


C. RECOMMENDED SEQUENCE WHEN DEVELOPING APPLICATIONS 

In this Section we will present a suggested sequence of steps when building 
applications, which in our understanding provides the best results mainly when dealing 
with medium to large programs. During this and the next few Sections we will be 
dealing with the same basic program in order to give you a better global idea of all the 
steps involved. 

For the time being assume that the requirements definition and the functional 
specification phases are completed and the architectural design is underway with all the 
modules and interfaces already defined. 

At this point since all the main modules with their interfaces are already 
specified, we can have a good idea of how many processors could we use to map our 


application, as well as which modules could be placed in different processors. 
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The experimental network will be as depicted in Figure 2.3 where we have 17 
transputers divided into 4 clusters with 4 transputers each, and one root transputer. 
The main purpose of this program will be to allow the novice OCCAM programmer to 
understand the structure of a TDS program, as well as how to configure a network of 
transputers. 

In this program the root transputer will be running the so called “hostproc’”, 
which basically receives a character typed on the keyboard and broadcasts it to four 
transputers, one in each cluster. Upon receiving the character, these transputers which 
will be running the process “route”, will route the character to each of the transputers 
left in that cluster. Finally, all the recipient transputers will echo back the same 
character to the root transputer, so that at the end of the program we will have 12 
characters printed on the screen. 

The next phase in the traditional software engineering life cycle is the module 
design, where all the interfaces between modules should be already defined. The module 
design is concerned with internal features of the module like algorithms, data 
structures, etc.... In OCCAM terms, the main goal of the module design should be to 
implement each module as an SC PROC, where all the communication between 
modules must be done via channels. 

Once we are ready to start developing our modules, we can either use the OPS or 
the TDS. This choice is not very clear, but seems to us that the OPS provides a nice 
timesharing environment for the early stages of the design, since we could have many 
users developing and testing their programs concurrently, under the VAX;VMS 
operating system. 

Once all the module design teams have their programs logically correct and 
running under OPS, they should be integrated as dictated by the previous architectural 
design, but still under the OPS, where all the interfaces between modules could be 
checked and validated against typical inputs. As one can see up to this point, no 
transputer hardware was necessary, and the reason we are emphasizing this is because 
if we had chosen the TDS instead, we would certainly have had a bottleneck problem 
in the usage of the BOO1 board, since it allows just one user at a time. Another main 
reason in using OPS lies in the fact that in doing so, we could use the powerful 
debugging tools running under the VMS operating svstem. 

The next step is a controversial one, where we transform an OPS program into a 


One-transputer TDS program; it will be entirely covered in the next Section. Although 


7a 





Figure 2.3. A Network with four Clusters, 
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it looks like a redundant step, I can assure to you that it is not; many bugs can be 
inserted into the program just by changing global definitions, changing library routines, 
inserting the now required terminal driver and mainly when trying to use the unique 
TDS constructs such as BYTE.SLICE.INPUT, WORD.SLICE.OUTPUT, etc... instead 
of the standard OCCAM channels i/o operations, which are much less efficient (2 to 5 
times) than the previous built-in procedures, as fully documented in the Reference 9. 
Of course this last change need not be done if you don’t have any sort of time 
constraints, otherwise they are crucial, since the differences in time are enormous. 

If for anything else, this step should be carried out in OPS, just because we have 
much better debugging capability than when running in many processors, and keep in 
mind that any multiprocessor program adds some new potential sources of errors, 
which are not always easily identified! 

Finally we should map this one-transputer program onto a n-transputer program. 
Where this “n” is dictated by the number of modules (SC PROCs) we have, which can 
be parallelized, and of course by the availability of processors. This conversion process 
will be described in Section E. 

As one can realize, this methodology will not help as far as real time debugging 
goes, but it will at least provide an effective way to achieve static logical correctness of 


the program. 


D. CONVERTING OPS INTO ONE-TRANSPUTER TDS PROGRAM 

According to our recommended sequence for developing applications, there will a 
point in time when you have developed your program under OPS and want to run it in 
a single transputer. In these cases you should proceed by checking all the global 
definitions to see if they are still applicable to a TDS program, for example, the 
channel Screen in OPS must be placed at “1” and the channel Keyboard at “2”, but in 
TDS this cannot be done, since "1" and “2” will correspond respectively to linklout and 
link2out addresses. Actually, in TDS the Screen and Keyboard are standard channels 
which communicate with the terminal driver routine and they don't need to be placed. 
Those are the basic differences between the global definitions for OPS and for TDS, 
but for further comparison refer to Appendices A and B, where we present both files. It 
is important to notice that these global _def.ops, global_defitds, library.ops and the 
library.tds files are not required by OCCAM, they constitute just another way of 


structuring a program, and making it easier to read and maintain. 
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Now if we look at Figures 2.4 and 2.5 we can see very easily all the steps 
involved in converting the OPS program.°> First, as already Suggested in the previous 
paragraph, we should change all the global definitions, as well as the library routines 
by the TDS equivalents. Second, you should include the terminal driver routine, which 
is used just in TDS, and place it in parallel with the main user process which was 
running under OPS. Third, change the PROGRAM fold which is embracing the whole 
OPS program by an SC fold, otherwise we won't be able to instantiate it in the 
configuration part. 

Finally, you have to do the configuration part, and since we are talking about a 
program to be run in just one transputer, the configuration becomes extremely simple, 
Where we have only the Processor number, followed by the name of the outermost SC 
PROC, with no channel parameters, since no external communication is going to take 
place. As you may have noticed. we inserted an additional fold of type PROGRAM 
embracing the SC and the configuration. This is not necessary, it only allows to 
compile and configure at the same time, otherwise you will have to apply the “compile 
utility” in both folds separately. 

Once vour program 1s successfully compiled in TDS and it is running properly, 
you could then try one more refinement step in order to speed up your program, and 
that is by using the unique TDS constructs like BYTE.SLICE.INPUT, 
WORD.SLICE.OUTPUT, etc ... instead of the standard OCCAM channels i/o 


operations like “chan ?” and “chan !”. When you are done, compile and run it again. 


Fk. MAPPING FROM ONE TO MANY TRANSPUTERS 

Although we recommend to perform the previous step in every program, we 
understand that the experienced programmer may skip that step for small or even 
medium programs, but when dealing with more complex programs with intensive 
communications between processes, it is strongly advised to run it first in one 
transputer, where you have more debugging capabilities and once it is proven to be 
logically correct and with no deadlocks, we should map it onto more transputers. 

The basic steps to accomplish this mapping are the following: 

l.> Kemove the outermost SC 2 OG 


2. Find those SC PROCs which have exactly the same code, differing just by the 
name and merge them into just one SC PROC with a common name. 


>For convenience we have marked with an asterisk all the changed lines in the 
converted TDS program presentedim ficwness 
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- PROGRAM echo.all 
: pe echo.all 
: Library def. pops 


ibrary.op 

C PRO Boetenoe (CHAN hostinO,hostinl,hostin2,hostin3, 
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Figure 2.4 OPS program. 


The terminal driver which was in parallel with all the SCs, must now be placed 


inside the SC PROC that will run in the root transputer. 
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PROGRAM echo.all 
SC PROC echo.all 


x  "|..F global_def.tds 
< ...F Library. tds ; 
SC PROC hostproc (CHAN hostin0O,hostinl ,hostin2,hostin3, 


hostoutod ,hostoutl ,hostout2,hostout3) 


SC PROC RouteOO (CHAN charin,charout,routetol,routeto2 
routeto3,echofroml ,echofrom2,echofrom3) 

SC PROC RoutelO (CHAN charin,charout,routetol,routeto2 
routeto3 ,echofroml ,echofrom2,echofrom3' 

SC PROC Route20 (CHAN charin,charout,routetol,routeto2 
routeto3,echofroml , echofrom2,echofrom3) 

SC PROC Route30 (CHAN charin,charout,routetol,routeto2 
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SC PROC echochar0l (CHAN charin,charout 
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SC PROC echochar31 (CHAN charin,charout) 

SC PROC echechar32 (CHAN charin,charout) 

SC PROC echochar33 (CHAN charin,charout) 
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a0 PROCESSOR O 
hs echo.ail 


Figure 2.5 “Converting vo ps: 


4. The global _def.tds and library.tds files should now be placed inside each of the 
SC PROCs which are going to be downloaded in different transputers. 
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5. Change the configuration to run the program in multiple transputers. This step 
will be covered in full detail in the next Section, so that for the time being we 
will limit ourselves to write down the header of the fold. 


The Step 2 deserves some additional explanation, and that is because when we 
are trying to map and run a multiprocessor program in just one processor, the only 
way to simulate very closely the structure of such a program is by making copies of all 
the procedures that are going to be ultimately downloaded in different processors, 
name them differently, and finally run them in parallel in the uniprocessor system. 

However, when making the final mapping onto more than one transputer, this 
redundancy is no longer needed, and it should be eliminated, in other words, all SCs 
containing the same code should be merged into just one, and at loading time the 
loader will take care of sending one copy for each processor, according to the 
configuration. Although this last step is not mandatory, we strongly recommend it, 
because in doing so you will be reducing substantially the code size to be downloaded 


to the transputer network, increasing the readability of the program as well. 


.. PROGRAM echoall 


ne Se PROC hostproc (CHAN hostino, hostinl,hostin2,hostin3, 
hostout0, hostoutl ,hostout2 whostout3) 


SC PROC Route (CHAN charin,charout,routetol, routeto2, 
routeto3,echofroml,echofrom2, echo from3) 


SC PROC echochar (CHAN charin,charout) 


configuration 





Figure 2.6 The Previous Program Mapped onto many Transputers. 


F. CONFIGURING A NETWORK OF TRANSPUTERS 

Let’s start by asking ourselves what is a configuration? Why ts it needed ? Well, 
the configuration is the way we have to specify which process is going to run in which 
processor and also to map the interprocessor channels onto the hardware processor 
links. This is accomplished by using some OCCAM] extensions like PLACED PAR, 
PROCESSOR number, PLACE channell AT address and CHAN channel AT address. 
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The code for any processor must be contained in a single SC PROC and the 
processor number can be any valid integer, which is just a logical identifier of that 
processor. However, the first processor to be declared must be always the root 
transputer, in other words, the processor connected to the host computer, which is the 
one responsible for bootstrapping and loading the code in the entire network. 

Each of the SC PROCs may be instantiated on any number of processors in the 
network, although it is exported from the host to the root just once. Further copies will 
be provided and sent by the root transputer to the others in the network. 

We have two ways of attaching software channels to hardware links, one is at the 
program level and uses the CHAN AT statement, and the second is with the PLACE 
AT statement which is used at the configuration level. The first one is optional, but if 
we don’t use it we must declare the channels explicitly as formal parameters to the SC, 
and they will be mapped to the actual parameters, at the time that SC 1s called or 
instantiated at the configuration level. On the other hand, if we decide to use the 
CHAN AT statement inside our program, the parameters to the SC PROC can be in 
any order and can have any name; the only thing that will be checked by the compiler 
is the match of the number of formal against the number of actual parameters. If you 
look back in our Figure 2.2 you will notice that we have used channels A, B. C, D, E, 
F, G and H as formal parameters, what suggest to us that we have to use some CHAN 
AT statements inside our process “user.n”. 

If there is a requirement to connect two links from the same processor, a soft 
channel must be used. 

A network configuration can be viewed as a PROGRAM consisting of a 
collection of SC PROCs which are instantiated from inside some PLACED PAR 
construct. SCs at this level must have just CHAN or VALUE tvpes as formal 
parameters. 

Let’s go now through the configuration of our old program echo.all where all 
these steps will be made much clearer for vou. Usually, after deciding how many 
parallel orocesses vou are going to have and how many processors vou are going to 
need, the next step is to define how they will be connected in a very broad sense. So, 
let’s suppose we want to run the echo.all program in the network presented in the 
Figure 2.3. 

Once the previous base steps have been accomplished, we suggest the following 
sequence of steps in order to properly configure a network of transputers: 


1. Number all the transputers using a structured ordering schema (see Figure 2.7). 
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2. Name the channels of the links used® to connect the different transputers. We 
suggest the use of an array of channels because it will allow you to make use of 
replicators as we will see later (see Figure 2.7). 


3. Place the correct process in each of the transputers in the network (see Figure 
2. 


4. Start making the placements for all the transputers in the network, just by 
reading directly from your sketch (see Figure 2.8). 


5. Instantiate the procedures such that the number of actual parameters matches 
exactly the number of formal parameters in the SC PROC. The order is 
irrelevant if we are also making the link placements inside the SC PROC. 


As demonstrated, the configuration is a very simple matter if we follow the 
suggested steps, but sometimes when we have more than one processor executing the 
same process, it is very likely that we will be able to recognize some fixed pattern in 
their connectivity, which will allow us to simplify the configuration by using some 
PLACED PAR replicators. That is why in the first and second steps we have suggested 
to use a structured ordering schema for the transputer number and an array of 
channels for the channel names. Now it is just a matter of finding a fixed pattern 
between the channel index, transputer number and its link number. Finally, after some 
reasoning, we were able to find-an equivalent configuration which is showed in Figure 
2.9. A further simplification could be to take out the placements of those hardwired 
links in the BOO3 board, but this will be left as exercise for the reader. 

This extra step 1s more an adornment than anything else, but it is strongly 
recommended when dealing with very large networks, because in doing so we will 
provide a better picture of our entire network. An experienced OCCAM programmer 
just by looking at the configuration, can have a pretty good idea of the connectivity of 
the entire network, in other words, if it uses a tree structure, a pipeline, a ring, etc... 
This feeling will be almost impossible if the processors are declared one at the time. | 

Two facts are important in this analysis, the first is to realize that no 
simplification would. be possible if there were no processors running the same process 
and the second is to understand that this embellishment in the configuration is not 
mandatory. | 

One of the points that we have just stated but didn’t cover in detail was the 
division of a program in a parallel number of processes. It is obvious that not every 


problem can be partitioned into smaller tasks to be carried out by different processors, 


©The channels from the hardwired links in the B003 board, do not need to be 
placed in the configuration part. 
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ECHOCHAR 
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Figure 2.7 Steps 1, 2 and 3 of a Configuration. 
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PLACED PAR 
PROCESSOR 100 


PLACE pipe[0O] AT linkOin 
PLACE pipe{1} AT linkOout 
PLACE pipe(2] AT linklin 
PURCE pipe leon Linklout 
PLACE pipe{4|] AT link2in 
PLACE pipe|{5j AT link2out 
PLACE pipe 5 AT link3in 
PLACE pipe}/.}, AT link3out 
hostproc (pipe tO] pipe} 2] pipet 2] pipes 
pipe{1],pipe{3],pipe(5j,pipe{7] } 
PROCESSOR 00 Piatas 
PLACE pipe[1l} AT linkOin 
PLACE pipe|[O| AT linkOout 
PLACE pipe({1l | Ar (inkl in 
PLACE pipej1l1] AT linklout 
PLACE pipe!8] AT link2in 
PLACE pipe({9| AT link2out 
PLACE pipe[1 AT link3in 
PLACE pipeil3} AT Link3out 
route ‘pipe tidy pipe[0 papell 
pipe{13],pipe[8],pipe [10 
PROCESSOR 10 i 
PLACE pipe[3] AT linkOin 
PLACE pipe|2} AT linkOout 
PLACE pipe|16] AT linklin 
PLACE pipe{17/ aT linklout 
PLACE pipe{14| AT link2in 
PEGE Dipe| lo, Ar .inkzout 
PLACE pipe{18} AT link3in 
PLACE pipe|19} AT Link3out 
route pipet 4; papel 2] gprs tte le gpipe ltt sy) 
pipe pipe[ pipe[16],pipe[ 
° 
0 
0 
PROCESSOR 32 | 
PLACE pipe taa4 AT linklin 
PLACE pipe|28} AT linklout 


echochar (pipe[{29],pipe[28] ) 
PROCESSOR 33 | 


PLACE pipet AL link2Zin 
echochar (pipe[31],pipe[30]) 


Ar JankZoue 


St 


PLACE pipe{30 


Figure 2.8 The Complete Configuration. 
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PLACED PAR 
PROCESSOR 100 


PLACE pipe(0O] AT linkOin 
PLACE pipe{1]} AT linkOout 
PLACE pipe{2}] AT linklin 
PLACE pipe/3]/ AT linklout 
PLACE pipe|4] AT link2in 
PLACE pipe[{5j} AT link2out 
PLACE pipe : AT link3in 


PLACE pipel 


noe Poe eee ttl pipes] oe 


PLACED PAR j = [0 FOR 4] 
PROGHSSOR. 202 | 

PLACE pipe[(2*j)+1] AT linkOin 
PLACE pipe[2Z*j| AT linkOout 
PLACE pipe/[10+(6*j AT linklin 
PLACE pipe | 114 o- AT linklout 
PEACH pipe o) aa) AT link2in 
PLACE pipe |o7(679 | Ar Lamizeoue 
PLACE pipe ee AT link3in 


MAT linksoeut 


PLACE pipe|,13+(6%j)} AT Link2oue 

route (pipe Z-a 4! ipe[2*j],pipe[9+(6*7) J, 
pipe Feats foipel (855) oe 18s (6*5)1, 
pipe{10+(6*j) | ,pipe|[12+(6*j ) 





PLACED PAR i = [0 FOR 4] 
PROCESSOR, (LU a i) sal 
PLACE pipe | 3+(3 4 AT link3in 
PLACE pipe([8t+ AT link3out 


echochar (pipe[9+(6*i)],pipe[8+(6*i)]) 
PLACED PAR i = [0 FOR 4] 


6*1 


PROCESSOR (10%i)+2 -:.... 
PLACE pipe eels AT linklin 
PLACE pipe({10+(6*1)|] AT linklout 


echochar (pipe[11+(6*i)],pipe[10+(6*1i)]) 
PLACED PAR i = [0 FOR 4] 

PROCESSOR (10*i)+3 4a 

PLACE pipe tee eat AT link2in 

PLACE pipe({12+(6%1)| AT LinkZ2out 


echochar (pipe[13+(6*i)],pipe[{12+#(6*i)]) 


Figure 2.9 A Simplified Configuration. 


but even if they could, at the actual state of the art, there is no automatic machine 
where we put the entire program as input and the machine would generate an optimal 


division of processes to be parallelized. 


38 


As a conclusion we should mention that this whole configuration procedure is a 
very simple one, even for very large and complex systems, and furthermore, the 
program can be developed with little or no thought to such matters and then, the 
required configuration can be performed after the program logic is proven to be 
correct. It is in this way that large and complex programs can be written while the 
actual hardware is still in paper design. 

Therefore, the key idea is that configuration does not affect the logical behavior 
of a program. It only enables a program to be arranged so that its performance 


requirements are met. 


G. CUSTOMIZING YOUR ENVIRONMENT 

When dealing with either OPS or TDS, it is extremely important to create a 
friendly environment to work, otherwise you will spend most of vour time performing 
unnecessary bookkeeping. The main reason for that is because a very big number of 
files is created for each complete cycle of a program,’ and since the default filenames 
for some of the above operations are pretty vague, it is important to define a more 
strict file naming rule. Some other areas are also affected by the lack of a consistent 
naming rule, for example, OPS and TDS programs are quite different but both use the 
OCCAM programming language, so that if we use the traditional file naming rules, we 
would end up with some name followed by the extension OCC for both programs, 
which is not recommended by obvious reasons. 

For all these reasons we have decided to make up our own file naming rules, 
which are described in Figure 2.10. 

When you apply the utility to get a printout of an OPS or TDS program, all the 
folds are opened and they come up as “--”, which is exactly identical to a comment in 
OCCAMI, so that to avoid confusion we will always use comments with ”---” instead 
of ”--”. This way, by looking at the printout, we will be able to very easily differentiate 
a fold from a comment. 

- Another decision we had to make was regarding the global definitions and the 
library routines each program was using. It was really messy to make a program, - 
because we had to pick up routines and definitions from different places, and finally 
put them inside our program, so that we decided to concentrate all in four files so 


called global_def.tds, global_def.ops, library.tds and library.ops. 


’For a cycle we mean the phases of editing, compiling, linking, extracting and 
printing. 


39 


-TDS => source code of a TDS program 

.OoPS => source code of an OPS program 

.occ => source code can de either [or TDS ore 
.LST => printable version of a TDS program 

-LIS = printable version of a OPS program 

.TcD > extracted transputer code (TDS) 

.EXE = executable VAX code (OPS) 

.OBJ => relocatable VAX code (OPS) 

.psc — descriptor information 

.CDE — non extracted transputer code 


Figure 210° File extensions: 


As a final step towards the customization of our environment we have made a 
login.com file for the VAX/VMS, where most of the commands are PC-like. See Figure 
aleks 


adraQ: L[occamjlopssetup 

ddrad: Loccam. tdsdiritdssetup 

set dir [occam.brasill/version_limit=20 

prot :== set protection = (owner:r,group:r,world:r) 
prot :== set prot = (o:rwed,g:re,w:re) 

d <== dir/size=used/width=(filename=28 )/columns=2 
cd :== set default 

md :== create/dir 


up :== set default [-] 


wre te er OP Pr Or OP WO 


ty :== type/page 


Figure 2.11 Sample login.com for the VAX/VMS. 
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Ill. OPERATING SYSTEM DESIGN 


A. WHY AN OPERATING SYSTEM ? 

As the program complexity increases and more processors are added to the 
system, some hardware limitations become more critical and a series of new potential . 
sources of errors are added to the program. In the transputer case for example, the 
four existent output channels will shortly become a bottleneck due to the increasing 
demand in communications, forcing the programmer to change the logic of his 
algorithm to comply with the actual architecture. Another problem that wiull arise is 
how to route a message to a non adjacent transputer in the network? How to output to 
the Screen from a remote transputer ? 

As widely known, the main purpose of any. operating system is to provide a user 
with the ability to use the system or a family of systems, without having to know the 
detailed hardware interconnections scheme for each specific system. In the specific case 
of the transputer, we have tried to follow this same line of thought, and after some 
reasoning, we have reached a very simple model for an operating system for a network 
of transputers. In our model, the user will be able to use simple primitives like “send” 
and “receive”, to perform the necessary intercommunication between processors. The 
main idea behind this approach is to release the user from the obligation of taking care 
of the channels placements, and all other implications, which are derived from this 
latter one. In other words, the user will not need to be concerned in how the message 
will get there. 

Another feature, which was included in our model, is the capability of sending 
two or more messages 1n parallel, to the same destination transputer, without having to 
assign or allocate several hardware links to handle this communication. The final goal 
is to make this another abstraction to the user, where the operating system would 
multiplex the different messages through the same hardware link, and this does not 
imply inefficiency, since the destination transputer would have to handle the messages 
sequentially anyway, afterall it is still a single processor. 

Once we have given sufficient reasons to support our claim, that a sort of basic 
Operating system for a transputer network 1s vital, let’s go into the other Section where 


we will try to cover all the steps of our design, in a very simple and practical way. 
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B. THE DESIGN 

Because of the fact that transputers have only local memory, a first approach and 
probably the only one at the current state of the art, was to employ a distributed 
operating system. An operating system kernel would reside in each node processor to 
supervise the user processes running on the node and to handle message traffic. 

The basic part of our design will be towards building an efficient communications 
system, but we will also provide some I/O handling, as well as some utilities like getting 
the real time, dumping memory, etc..., from “any transputer” in the network, which will 
greatly enhance the overall debugging capability of the network, and it will make it 
much easier to program. 

One of the first design issues to arise was regarding the protocol to be used in 
our communication subsystem, more specifically, what kind of information should be 
carried by the message header. | 

The first needed information, and also the most obvious one, is the transputer id 
number, which will identify the destination transputer for a message. This number, as 
we will see later, must be in accordance with the routing table, since it will be used as 
an index to retrieve information from this table. 

The second information to be carried by the header is the message size, since we 
have .decided to support variable length messages. Here we had a trade off between 
versatility (variable length), and efficiency (fixed length), but in this case we have 
chosen to go towards the first one. 

The third header component is not an obvious one, which is the channel id 
number. It must be unique® in the entire system. This channel id will allow the system 
to determine within one transputer, which process, and ultimately, which channel 1s 
supposed to receive that message. 

Therefore, the header which we will be using throughout our system is four bytes 
long and has the format specified in Figure 3.1. 

We could have used an integer value, which is also 4 bytes long, to carry all the header 
information, but it would take too long to decode it, and besides, the time to output 
four bytes with the BYTE.SLICE construct is approximately the same as to output an 


integer [Ref. 9]. The difference in decoding time is because with the byte structured 


8A fter looking at the implementation, it will become evident that the uniqueness 
of the channel id is a very important requirement, since otherwise it may lead to 
dubious results. However, it could be eliminated if we have added another field, the 
transputer origin, in the header of our protocol. 
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——| 
= MESSAGE ania —— BLOCKSIZE 


BYTE 3 





Figure 3.1 The Message Header Format. 


header we just have to fetch the proper field and we are done, while with the integer 
header we will have to perform some additional arithmetic operations like divide, 
remainder, etc....: 

| In the introductory Section of this Chapter we have discussed some nice features 
to have in our system, but how could we implement them, keeping the entire process as 
efficient as we can ? Certainly, the answer at a first glance does not appear to be very 
simple, since we can have so many different communications paths as depicted in 
Figure 3.2. For example, one internal process of transputer #X could be trying to 
communicate with another internal process in the same transputer, or this same 
process could be willing to talk to a process in transputer #Y, etc... and keep in mind 
that in the worst case we could have “any number” of internal processes trying to 
communicate between each other, and “any number” of processes trying to talk to 
remote transputers through the four output links, and if that is not bad enough, we 
could have the four input links receiving messages either for some process in this 
transputer or to be bypassed to some other transputer in the network, and remember 
that all this could be happening in parallel, except for the internal processes 
communications which would be done in a timeslice fashion, but they could be still 
inside a parallel construct. 

In the previous paragraph we have said that “any number” of processes could be 
trying to output through the four output links in parallel, and this statement deserves 
an additional explanation. In the actual OCCAM implementation this could never be 
done, because just four software channels could be attached to the four existent output 
hardware links, and therefore we could have at most four links trying to output at the 


Same time, but since it was a design decision to keep the interface between the user 
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Figure 3.2 The Possible Communications Paths. 


processes and the hardware channels as abstract as we could, we are going to 
implement this extra feature in the Operating System model. For example, suppose we 
had a case where the algorithm to be implemented had to send two messages in parallel 
to some transputer X. If we had decided to use straight OCCAM, although “logically” 
a parallel operation is what we want, in practice the programmer would have to either 
change the logic of his algorithm because of the above mentioned physical limitations, 
or he would have to assign a second hardware link to that same transputer X, what is 
not recommended by obvious reasons. Thus, What we tried to do is to take this 
preoccupation from the programmer, by building a sublaver of software which would 
allow any number of output requests to be placed in parallel, even if they have the 
Same transputer as destination. 

Let's make up an example, where some transputer is receiving, in parallel, a 
stream of external values from three distinct transputers. It must calculate their totals 
and send them to three parallel processes running in another transputer, using the 
remaining link (see Figure 3.3). The current solution to this problem would be to 
output the totals in any sequential order with no concern about the order they became 
ready, in other words, the first total in the sequence could happen to be the longest to 


calculate and as result we would be blocking the other totals to be sent, delaving the 
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entire process. With our new approach, the programmer could maintain the algorithm 
logic by sending them all in parallel, and leave to the operating system the task of 
multiplexing them through the output link? as they became ready. You should argue 
that we could have used the “ALT” construct and get the same final result, and that 1s 
partially true when dealing with non adjacent transputers, but the problem is that it 
blocks the other processes until that first one is done, therefore, in the extreme case it 
could even block them for ever. On the other hand, with the “PAR” construct if some 
process is taking too long, it will timeout and the scheduler will put the next readv 
fnocess [0 execute. 

It 1s also worth pointing out, that when we have many transputers in the 
network, it becomes much more complex, since we won't know whether or not the final 
destination 1s ready to receive that message, so that as a general rule, avoid as much as 
you can to use time dependent algorithms, because they are very likely to deadlock the 
system. | 

Another decision we had to make was regarding the usage of multiple buffers for 
storing incoming and outgoing messages, which were not ready to be received or 
delivered. What we were trying to achieve with multiple buffering, was to keep the 
communication paths free for any messages which might be trying to bypass that 
transputer, in order to get to its final destination. 

However, after some thoughts and after making some rough implementations, we 
have reached the point where in order to maintain multiple buffers, we would have to 
lose the parallelism in the input links, because there was no way to get around using 
the OCCAM1 programming language, and also the overhead imposed to manage the 
buffers pool seemed to be very large, turning it to be less efficient than with just one 
buffer. So, in the actual implementation as we will see, any incoming message to a 
transputer will be stored into the Operating System buffer space, tieing up the channel 
where it came from, until it 1s either consumed by some process in that transputer, or 
bypassed to some other transputer in the network. On the other hand, if it is an 
outgoing message, it will be kept in the user’s memory space of the transmitting 


transputer, having no effect on the bypassing traffic. 


"Have you noticed in Figure 3.3 that we have used an array of channels in our 
proposed solution ? The reason for that will become completely clear after reading the 
implementation Chapter. 
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PAR 
linkOin ? stream0 -== frometyancpire aa 
Janklan 7 stream === from Eranspuccwerc 
link2in ? stream2 --- from transputer #4 


... evaluating the 3 totals 


PROGRAMMER'S INTENTION 
(not allowed) 


PAR 
linksout P torald transputer #1 
inkesour? | yeocat transouter 
link3o0ut total2 transputer #1 


CURRENT SOLUTION 


SYD 
iantoeee totalod transputer 
linksout.! (toga transputer : 
link3out total2 transputer 


OUR PROPOSED SOLUTION 


totald --- to transputer #1 
GoGo ie. --= {0 transeuter 
total2 --- to transputer #1 





Figure 3.3. An OCCAM Limitation. 
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As you can see, we will have to deal with all kinds of mutual exclusion problems, 
since well have in most of the cases many more parallel requests than available 
‘resources (links), but here is where the transputer architecture, as well as the OCCAM 
construct “ALTernate”, become very handy. The first one by providing a built-in 
process scheduler with two priority levels, a timer and a memory management unit, and 


10 a5 we will 


the second by providing a trivial solution to the mutual exclusion problem, 
see later in the next Chapter. 

Now arises another problem, how could we route an incoming message to the 
correct internal process it is supposed to be routed to ? One solution could be to 
create in each transputer a channel-id table in memory (see Figure 3.4), where we 
should have all the channels which communicate with external transputers and one id 
number associated with each of these channels. Obviously, the id number would have 


to be carried by each message using that specific channel. 


CHANNELS [> 


eo a 
Theater | a 


fron.rades [ae 





Figure 3.4 A Sample Channel-id Table. 


Another solution that came up after some unsuccessful trials with the channel-id 
table, and also a much better one in our opinion. is the idea of creating an array of 
channels, where the id number could be the subscript of the array itself. Simple, is it 
not ? Also this decision would make our mutual exclusion handler much simpler, as 


you will see later in the implementation Chapter. 


10Y would like to emphasize that as you may recall, this is one of the most 
traditional and difficult problems when building operating systems. 
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As you can see, in our abstraction model we will have our Operating System with 
the control of all the hardware link communications and with an user interface that will 
allow the user processes to communicate with the outside world in a very simple way. 


See hicwne ss: 


TRANSPUTER 


input links = OPERATING SYSTEM output links 


USER INTERFACE 


USER 


PROCESSES 





Figure 3.5 User Abstraction. 


Therefore, based upon all the previous design decisions, our Operating System 
will present the following characteristics: 


e = =[ft will support a maximum of 256 transputers in the network, but since we are 
using, for convenience, a routing table which supports only 18 entries, it will be 
limited to I8 transputers. This can be very easily modified, and it will be 
explained in the Section covering the routing table. 


e [It will support a maximum of 256 user channels active at one time, for 
conimunications with other transputers. -\ctually this number will drop to 20 
channels as we ll see in the implementation Chapter. 


e it has no limit to internal soft channels. 
e the maximum message length supported is 64 Kbytes. 

As we can see, we have much more than we will really need for most typical 
applications, so that our protocol could be very easily modified and optimized. In 
Chapter VI we will evaluate two versions of the operating system, one with a 4 byte 
header, and the other one with 3 bytes, and we will be able to see, very clearly, the 


effect of the header size in the transfer rate. 
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Let’s now cover more in detail the block components of our Operating Svstem, 
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Figure 3.6 Operating System Block Diagram. 


1. Input Handler 


as well as all the data and control flow that is going on in there. The major blocks 
which compose our Operating System are the Input Handler, the Screen Handler, the 


Output Handler and the Operating System Library Routines as depicted in Figure 3.6. 


LINK 4 


USER 
PROCES 


The Input Handler is composed of three basic blocks, the decoder and buffer, 


the bypass handler and the software channel input interface. 


There will be one decoder and buffer for each of the four input links and its 


the operating system buffer. 


49 


function is basically to receive the header, decode it and store the incoming message in 


The four bypass handlers will be activated by the respective header decoders, 
upon arrival of a message to be bypassed, and then, they will issue a request to the | 
output handler, using a special soft channel, which will be uniquely identified by the 
link from which the message is coming and by the link through which the message is 
going to be forwarded, to get to its final destination. Once the output handler accepts 
its request, the bypass handler will release the decoder to go ahead with the 
retransmission of the message by the desired link. 

The software channel input interface will be activated just when the message is 
for that transputer, and it will perform an additional check to see if the message is 
addressed to the Screen channel, in which case it will request permission to the screen 
handler to use its controlled resource. However, in both cases it will send the releasing 
order back to the decoder, which will send the message either to the screen, or to the 
appropriate channel in some waiting process. 

2. Output Handler 

This module is responsible for enforcing mutual exclusion in the four output 
links. Basically it will handle two kinds of messages, the outgoing ones which are 
generated by internal processes, and the bypassing ones which are coming from 
external sources, and just want to use that transputer, as a retransmission station. 

This module is always listening to all possible channels, in such a way that 
any output request will be accepted almost immediately. Once a request for output in 
some specific link is accepted, that means that the requestor can go ahead with the 
transmission through that link, with the guarantee that no collisions will happen. As 
you can see it acts much like an air controller in an airport with four parallel runways, 
where besides ensuring mutual exclusion to each of the runways, he will keep them 
working 1n parallel. 

3. Screen Handler 

The Screen Handler will make sure that just one process from “any transputer™ 
is holding control of the screen port at one time. Much like the output handler, once a 
request is accepted, the requestor is ‘guaranteed free usage of the resource with no 
inverierence. 

It is important to mention that all the communications between modules and 
submodules of our operating system, are done strictly via control flags, with no data 
flow until the very end of the process. Another point is that for efficiency purposes, we 


are allowing some user accessible routines like “send” and “receive”, to have direct 
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contact with the hardware links, but this will not cause any problems, because their 


execution 1s completely controlled by the operating system modules. 


5] 


IV. OPERATING SYSTEM IMPLEMENTATION 


We will discuss in this Chapter all the steps and peculiarities of our 


ll 


implementation, ~ as shown by the source code contained in the Appendix D. 


A. INPUT HANDLER 
The general structure of this module 1s presented in Figure 4.1, where we can see 
that it is all the time listening to the four input links in parallel. and as soon as we 


have any incoming message, it will be readily consumed by the proper link. 


PROC input.handler = . 
. variable and constant declarations 
SEQ 
. initializing the buffers 


WHILE TRUE 
listen to linko 


WHILE TRUE | 

$2 Sibel CO sl imikt 
WHILE TRUE 

‘eaeerseen EO Unie: 
WHILE TRUE 

wee Listen to links 





Figure 4.1 A General View of the Input Handler. 


Hereafter, we recommend vou to follow closely the source code contained 1n the 
Figure 4.2 for a better understanding of the program. After receiving the header with 
the BYTE.SLICE.INPUT built-in procedure, we start decoding the block size. You 
should ask why to decode the block size right away, even before knowing if that 
message 1S going or not to be bypassed, but as vou will notice later, even for bypassing 
the block size will be required. 

Once we have stored the message in the buffer of the respective link, which 1s 
maintained by the Operating System, we can proceed with the decoding. The buffer 


size iS a very important issue, and it should be adjusted to the lengthiest message 


Il At this point is highly recommended that the user have already been exposed to 
the OCCAM1 programming language and to the Transputer Development System for 
the VAX/VMS. 


ey 


expected to travel in the network. This adjustment is carried out by changing the value 
of the constant “max.block.size”, located in the very top fold named “Operating System 
Global Declarations” (see Appendix D). The reason for that is because the compiler 
needs to allocate memory in advance for those buffers, and remember that we have one 
buffer per input channel. 

Since we have to spend an appreciable time initializing the buffers,!* and also 
because We have very strong memory limitations in the BOO1 board (64K), it is a wise 
idea to use strictly the necessary buffer size. As we will see in Chapter VII, this buffer 
size can be modified by changing a constant value called “max.block.size”. 

If the message is not for this transputer we calculate the output link by looking 
up in the routing table for that transputer. This table must be provided for each 
transputer in the network during the configuration phase, it will be covered more in 
detail at the end of this Chapter. But for the time being, it is sufficient to know that its 
indexes are the destination transputers id numbers, and the correspondent values 
fepresent the output channels to be used in order to reach those transputers. 
Therefore, the only valid values in the table are 4, 5, 6 or 7. 

So far we haven't done anvthing fancy, but now comes the subtle point, I may 
say the most important and nice concept of the whole system. As you can see, when 
we send a flag to the output handler, requesting a “green sign” to go ahead with the 
retransmission of the header and the message, the soft channel used to send the flag 
must carry the necessary information, in order for the output handler to be able to 
recognize specifically, who is requesting permission, and which output link that request 
is for. The reason it must keep track of information like this is because many different 
users might be requesting permission to output through the same link. Now comes the 
question: how can we pass this information to the output handler without having to 
send extra bytes of information, and at the same time keeping this switching of 
processes as efficient as we can ? The answer we came up with was to use an array of 
channels whose indexes obeyed a special law of formation. 

If you take a close look at the code, you will see that the channel indexes will 
carry all the needed information, in other words, who is requesting and what is being 
requested. So that, channels 04, 05, 06 and 07 will be used by any message received 
through link 0 that wants to be retransmitted by links 4, 5, 6 or 7 respectively. 


124 though this is not a required step, it is believed that in not doing it, we may 
have some strange results, due to some problems in the code generation of the 
OCCAM 1 compiler for the VAX. 
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WHILE TRUE 

-- listen to linkl 

SEQ 
-- receiving the header 
BYTE.SLICE.INPUT (linkl,headerl,1,header.size) 
-- decoding the block size 
block.sizell[0] := ((256 * headerl [BYTE 1]) + headerl [BYTE 2]) 
-- buffering the message 
BYTE.SLICE.INPUT (linkl,buffer.inl,l,block.sizell[0]) 
cE 


-- the message is to be bypassed 
headerl [BYTE 4] <> this. transputer 
SEQ 
-- finding the best link to output that message 
outl := route.table {headerl [BYTE 4]] 
-- outputing to the required link 


BYTE.SLICE .OUTPUT( chan[10+0utl],headerl,3,1) --- start flag 
--- thru chan 14, 
IF --- 15,16 or 17 
outl = 4 
SEQ 


BYTE.SLICE.OUTPUT (link¢,headerl,1,header.size ) 
BYTE.SLICE.OUTPUT (lLink4,buffer.inl,l»,block.sizel[0]) 
outl = 5 
SEQ 
BYTE.SLICE.OUTPUT (link5,headerl,1l,header.size) 
BYTE.SLICE.OUTPUT (link5,buffer.inl,1,block.sizel[0]) 
outl = 6 
SEQ 
BYTE .SLICE .OUTPUT (link6é,headerl1,1,header.size ) 
BYTE.SLICE.OUTPUT (link6é,buffer.inl,1,block.sizel[0]) 
outl = 7 
SEQ 
BYTE.SLICE.OUTPUT {( link7,headerl,1,header.size) 
BYTE.SLICE.OUTPUT (link7,buffer.inl,1,block.sizell[0]) 
BYTE .SLICE .OUTPUT ( chan[10+o0utl ],headerl,3,1) --- end flag 


-- the message is for this transputer 
headerl [BYTE 4] = this. transputer 
SEQ 
IF 
headerl [BYTE 3] <> scrn --- if channel.id <> 40 
SEQ 
-- passing the size of the message (block.sizell[0]) 
WORD.SLICE.OUTPUT (chaniheaderl [BYTE 3]],block.sizel,0>,1) 
-- passing the message itself 
BYTE.SLICE.OUTPUT (chanlheaderl [BYTE 3]],buffer.inl>l, 
block.sizel[0]) 
TRUE --- if channel.id = 40 = Screen 
SEQ 

-- I'm ready 
BYTE.SLICE.OUTPUT: (screen[1],headerl1,3,1) 
-- output to the screen 
send.string (Screen, buffer.inl, 1, block.sizell[0]) 
new. line(1) 
-~ I'm done 
BYTE.SLICE.OUTPUT (screenl11],headerl1,3,1) 


Figure 4.2. Input Handler Source Code (Partial). 
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Likewise, channels 14, 15, 16 and 17 will be related to link I, channels 24, 25, 26 and 
Peevelink 2,-and finally channels 34, 35, 36 and 37 to link 3. Therefore, these will be 
operating system reserved channels and must not be used as user channels. Remember, 
there will be no checking for this error, so that if you use these channels inside your 
program it will very likely deadlock the system. 

When the retransmission of the message is finished, the requestor sends another 
flag to the output handler, to let it know that the output link may be freed or used by 
the next in the queue. 

On the other hand, if the message is for this transputer, then a further check will 
Bemimade tO see if the message is to be sent to the screen or to some internal user 
process. This check is needed because in our implementation a message sent to the 
screen does not require a receiving process in the root transputer, whereas in the other 
case it is mandatory. Obviously this step will be carried out just in the root transputer, 
and this will be the basic difference between the operating system for the root and for 
the other transputers, since the root transputer is the only one to have a port attached 
to a terminal. 

When the message is for some user process, the block size information is still 
needed, since the user process must know what is the length of the message it is about 
to receive, otherwise it will have no way to know when to stop receiving. This 
additional overhead arises from the fact that we are allowing variable length messages. 

The screen channel is defined as channel “scrn” or “40”, and it is another 
operating system reserved channel. Once we receive any message addressed to it, we 
will need to request permission to the screen handler, as we have done previously with 


the output handler, to go ahead and send it to the terminal. 


B. OUTPUT HANDLER 

Although the Output Handler looks very simple, it performs a very complicated 
task which is to assure mutual exclusion for each one of the output links. 

As can be seen in Figure 4.3, all the channels with termination 4 will be polled 
through the first OCCAM alternate construct (ALT) to check if there is anyone 
requesting access to link 4. Similar action is being held for each of the others output 
links, with all of this being done in parallel. If there is any request for output through 
the hardware links, it will accept the request and will lock up that link until the user 
tells him that he is done. The main issue here is that the termination of the soft 


channel id, determines which link that channel wants to uSe as output. 


3D 


PROC output.handler = 
-- local variable declarations 
VAR flag4 [BYTE 2]: 
VAR flagS [BYTE 2]: 
VAR flag6 [BYTE 2]: 
VAR flag7 [BYTE 2]: 


PAR 
WHILE TRUE | 
ALT i = i FOR ere eee cgeot | 


chan [(10*1) +4] ? flag4 ae 0] --- fon Llink4 
BYTE .SLICE.INPUT (chan [(10*i) +4]) Elaqamomn 


max.io.channels | 
1) +5 joe we lags ee 0] --- for links 
BYTE.SLICE.INPUT (chan [(10*}) +5],flag5,0,1) 
WHILE TRUE 
ALT k = a FOR max.1o.channels] 
chan [(10*k) +6] ? flag6 vee 0] --- for link6é 
BYTE.SLICE.INPUT (chan [(10*k) +6],flag6,0,1) 
WHILE TRUE 
ALT 1 = ts FOR max.io.channels |] 
Chan [(10*1) +7] 2 flacgieesyTe Gn --- a Link? 
BYTE.SLICE.INPULT (chan | (10*L) +7 eeetaag. 3 me 





Figure 4.3. The Output Handler. 


Although it is not clear at a first glance, due to the way that the replicator ALT 
is implemented in OCCAM1, we are having a sequential, rather than parallel, output 
through the links 4, 5, 6 and 7. Let’s suppose we have somewhere in time the following 
channels requesting output in parallel: chan{17], chan[4], chan[{35], chan[54], chan[76], 
chan($4], chan[{107] and chan[66] (see Figure 4.4). We should be able to realize by now 
that the first three channels are reserved channels and carry some messages which must 
be bypassed through links 7, 4 and.5 respectively. On the other hand, the remaining 
five channels are being used by some internal user processes running in that transputer, 
which want to use, respectively, links 4, 6, 4, 7 and 6 for output. What we should 
expect by looking at our implementation of the output handler (see Figure 4.3), would 


be to have the following sequence of transmissions, !? 


as depicted in the Figure 4.4, but 
what actually happened was a sequential transmission in the following order: chan{17], 
chan{4], chan[54], chan[84], chan[35], chan[66], chan[76] and finally chan[107] (see 


Pigure:4%5). 


l3We have assumed the same length for all the messages just for convenience. 
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Figure 4.4 The Expected Behaviour. 
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Figure 4.5 The Actual Behaviour. 


Based on the previous results, we couldn't come up with a rcasonable 
explanation, other than some problem in the code generation of the OCCAMI1 
compiler for the VAX/VMS. 
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After many different trials we have finally got a way to implement it truly in 


parallel, and it came up with the odd structure presented in Figure 4.6. 





eee TRUE 
goingl TRUE 

going2 

going3 

oing4 TRUE 

AR ; 


WHILE goingl 
ALT j = Ma FOR MAX » aCe channels] 
chan [(10%*j)+4 a 
ee (Sh ren. SUTPUT Te an{ (10*j)+4],flagl,1,1) 
goingl := FALSE 
WHILE going2 
SLL : z 
ALT k = i? FOR max.actual.channels| 
chan, | Cl0-\)4 Sec ape 
one Ses SELGE. oUTPUT(e an[ (10*k)+5],flag2,1,1) 
going2 := FALSE 
WHILE going3 
ALT 
ALT l = i FOR max. tee channels ]} 
chan [(10%1)+5] ? ae 
ne eee SSL LCE. atone an[{ (10*1)+6] ,flag3,1, ) 
going3 := FALSE 
WHILE going4 
ALT ine 
ALT m = ua FOR max. eoluere channels] 
chan [(10%*m)+7] ? aa 
caeuHeoe ,oULCEe Tea an{ (10%m)+7],flag4,1,1) 
5 


going4 := FALSE 
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Figure 4.6 The Parallel Solution. 


However, this was the only way we found to trick the compiler. With this structure we 
had the expected parallel output, in other words, each link transmitting in parallel, 
exactly like depicted in Figure 4.4. 

If the reader looks at the final implementation of the Output Handler, he will 
notice that we have used the first structure, rather than the second one. There are some 
reasons for that, the first one is because we have assumed that it will be very unlikely 


to have such a situation where all the channels will be ready exactly at the same time 
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and furthermore, we are talking about more than one message ready for each of the 
links at the same time, what you should agree that will be quite unusual, but 
nevertheless, the most important reason was that after evaluating both structures, we 
have ended up with a very big difference in execution time towards the first one, being 
more specific, it Was in average about 5.6 times faster than the second one ! Actually, 
this could be partially expected just by looking at the overhead imposed by the second 
structure. 

Now you can realize why we have chosen an array of channels, instead of using 
generic names for those channels which communicate with external transputers. Stop 
and think how difficult and cumbersome it would be, to make an alternate construct 


with generic names for their guards.!4 


C. SCREEN HANDLER 

The idea behind this procedure is exactly the same as the output handler. The 
main difference is that it will take care just of one channel, the Screen. 

If any other transputer wants to output to the screen, the only thing it must do is 
to use the standard “send” routine, which will be covered later in the Section dealing 
with the Library Routines, and send any message he wants through the Operating 
System reserved channel 40, also defined as “scrn”. 

Once this has been done, the message will arrive at the input handler of the root 
transputer, and after being decoded it will end up in requesting permission to the © 
screen handler to output the message to the screen. If you look carefully in the input 
handler code, the software channels screen[0], screen[1], screen[2] and screen{3] are 
directly related to messages coming from external sources. If some process in the root 
transputer wants to output something to the screen, it will use additional software 
channels allocated for it in advance. In the actual implementation we have reserved just 

two more screen channels for the root transputer, screen[4] and screen[5], but this is a 
matter of just changing the constant “max.screen.channels”, which is located in the 
“Operating System Global Declarations” fold, and you will be able to have as many as 
you need for your application. 

This feature actually improves the capability of the programmer, since he had 
prior to this implementation just one possible channel for writing to the screen, and 


now we can have as many as we want. Obviously, due to physical limitations (we have 


\4Guard is the name given for the channels which are being polled for input by 
the alternate construct. 
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just one port to the monitor), we will have a sequential output, but in doing so we are 
taking from the user the need to worry about this matter, in other words, we are 
providing to the user a higher level of abstraction. 

However, the beauty of all this about the screen, is that we have now the 
possibility of debugging remote transputers, what we didnt’t have before. Now we can 
even trace the execution of all our processes running in the entire network, by just 
sending a flag to the screen when entering in some procedure and when exiting it. Of 
course it won't be in real time, but at least we will be able to have a precise idea of the 
entire flow of control in the network. 

If we have the case where four transputers may try to output to the screen at the 
same time, we won't know which is which, so that we must send a unique message 
which characterizes the transputer it 1s coming from. This little problem could be very 
easily solved by inserting the origin transputer id in the message header, but for 
efficiency purposes we decided not to implement it. 

Finally, vou might have already noticed that the output to the screen from 
remote transputers, is the only send operation which does not require any other receive 
operation in the root transputer. This is a basic point, since for every send operation 
ought to have a receive operation for the same channel id somewhere in the network, 


otherwise the system will deadlock. 


D. THE ROUTING TABLE 

The routing table is the instrument that will provide to the operating system, the 
necessary information regarding the routing of messages. For example, if we receive a 
message which needs to be bypassed, the O.S. based on the destination transputer id 
for that message, will look up in the table and see which is the recommended link to 
output that message. Once this has been determined, it will follow the standard steps to 
input or output a message, as already discussed in previous Sections. Similar action 
will be taken for internal messages, which want to be forwarded. 

In the first implementation of our system, we put the routing table, as well as the 
transputer 1d number, as global variables inside each of the SC PROCs to be 
downloaded to the network. Although this way is much simpler to implement, it 
presents a very serious limitation, and that happens when we want to load basically the 
same SC PROC in several transputers, just differing by its id number and by its routing 
table. If that was the case we would have to make as many as needed different SCs, 


which is completely wasteful. So, we decided to pass the transputer id number and the 
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routing table as constant parameters in the configuration, but since OCCAM1 does not 
support tables as parameters in the configuration,!> the only solution was to pass value 
by value, and if we follow the code we will see a fold in the top of the main program of 
the operating system, where the entire routing table is received. | 

Another point to mention is that our routing table was limited to 18 entries 
because we have just 18 transputers in our Lab. But if for some reason we need to 
change it, we must carry out the following steps: 


1. Change the route.table declaration, which is located in the “Operating System 
Global Declarations” fold, in each of the files ROOT_OS.TDS and 
Re vViOTE OS:7 Ds: 


2. Add as many new parameters as needed to each of the SC PROCs to be 
downloaded in the different transputers; 


3. Go to the main body of the PROC “operating.system”, where the routing table 
is actuallv received, and assign the new parameters from the previous siep, to 
some new indexes of the routing table. Try to be consistent with the 
assignments which are already in there; 


4. Inthe configuration Section, add the new values to the parameter list of each Of 
the SC PROCs, much like you did in step 2; 


After building the routing table, the user must check it for the non existence of 
cycles in it. If that happens, it will be very likely that some of the messages will never 
arrive in their final destination, constituting a very difficult problem to isolate. Hence, 
- it is strongly recommended to perform this test, before using a new routing table. 

As the reader can notice, our routing table is nothing else than a graph, so that if 
the table is very large, it is recommended to make a little program to detect cvcles in It. 
There are many algorithms to detect cycles in a graph, which might be found in any 
book covering Graphs. However, if the table is small, it is quite simpler to check it by 
hand. 

Suppose We are given a transputer network and a routing table, as specified in 
Figure 4.7. The routing table specify the output links, which must be used by the origin 
transputers, when they desire to send some message to the destination transputers. 

We suggest the following algorithm: 

1. Select a column, in other words, a destination transputer; 


2. Select an origin transputer, one at a time, and use the output link listed in the 
table, to find by looking at the network, where the message will be directed to; 


I>Tt is believed that the new beta release version of OCCAM2 for the VAX/VMS 
will support tables as parameters in the configuration. 


61 


3. If the transputer obtained from Step 2, is not the destination transputer, jump 
back to Step 2 and use the latter one as the new origin transputer, otherwise, 
proceed to Step 4; 


4. If you have got a cycle when executing Steps 2 and 3 stop, modify the routing 
table, and start all over again, otherwise, jump back to Step 1 and select 
another column, until all columns have been selected. 


E. OPERATING SYSTEM LIBRARY ROUTINES 

What do these libraries contain ? Is it required to put them in any TDS program? 
As explained in Chapter II, the answer is “no”. They are not required to be inside a 
file, a fold or whatever, but this was the way we found most attractive, logical and 
easy, to handle the increasing number of new procedures, which were created along our 
research. The basic idea is to update the library whenever someone in the research 
group, has made a routine which might be useful in the future. However, it will be 
useless if 1t is not very well documented, tested and validated for all expected inputs. 

| Following this line of thought we have built basically two. libraries, the first one 
for the root transputer, and the second one for remote transputers. Both are completely 
described within Appendices D and E, which present the source code for the root and 
remote operating systems. 

Although they have almost the same routines, they have quite a few differences 
in their 1mplementations, as we should expect. However, it 1s not our intention to 
provide a deep explanation of all the code contained in those libraries, but the 
interested reader is welcome to go into the source code, which we have tried to 
document as well as possible. 

The only routines which we will cover in detail are the “send” and “receive” 
routines, which are the basic interface to the user, and also the most tmportant 
procedures to handle communications in the network. 

1. The Send Routine 

When we want to send a message to an external transputer, this is the nght 
procedure to call. It is one of the two only routines, which can access the modules of 
the operating system directly. It is also, as we will see later, the only routine that can 
output directly to the hardware channels, but obviously under control of the operating 
system. The fact that we are allowing a user accessible routine to talk directly with the 
hardware output link, may cause the unpleasant feeling that we are not following our 
previous abstraction model for our system, but that is not correct, since the operating 
system is still with the control over that link. Furthermore, we have tried other ways 


and this was by far the most efficient one. 


62 


DESTINATION 


ZH HH wR © 





ROOT TO Lz T2 T8 


ROOT TO Til T2 T8 


@ ® 
8] oO 
ROOT TO fj ey T2 T8 
e oO 
a 
ROOT TO 6 wat T2 T8 


@ e @ 
oO 8] 
ROOT TO Ti T2 T8 
© @=—=————- f © © 
Oo ‘e] 
ROOT To Ti T2 T8 
: a 
0 
0 
0 
Oo 


\ - 


ROO 
ae ates a van yr CYCLES | 
0 
ROOT To Ti—<«T2 T8 
0] 

0 

ce) 

@ 


Figure 4.7 Checking the Routing Table for Cycles. 
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It is inside this procedure where the header is constructed, using the 
information provided by the user. Another important point to raise is that for any 
“send” we must have a “receive” for that same channel id, exactly at the destination 
transputer for that send. The only exception is in the case of the channel “40” or 
“scrn”, where we don't need to have a receiving process for the send. 

The following parameters must be passed to this procedure: 


e The channel id which is an integer value multiple of 10, in the range of 40 up to 
240. Remember that channels 0 up to 37 are operating system reserved channels 
and cannot be used inside our program. The only reserved channel that we can 
make use of. is the “40”, which is uniquely assigned to the Screen channel, but 
even though, we cannot use it to send messages to transputers others than the 
root; 


e The destination transputer id is a unique integer value which characterizes a 
transputer. The value assigned to it must be inside the range of our routing 
table, in other words, if we have a routing table with 18 entries, the id numbers 
must be between 0 and 17 including both endpoints; 


e The start bvte is the position of the first byte in the array that we want to send. 
Obviously it cannot be negative. It is important to remember that an array in 
OCCAM always start from byte 0, so that “start.byte” equal to 0 1s a valid 
entry. However, always keep in mind what we really want to send; 


e The size is the number of bytes to be transmitted. If we want to send the 
message from some specific start byte up to the end of the array, we don’t have 
to make any calculations, just put “0” as the size value. However, in using this 
latter approach, it is mandatory that in the byte 0 of this array we have its size 
information, as it is usually done in OCCAM1. 


send (VALUE chan.id,dest.transp,message{ ],start.byte,size) 


USAGE: send (60,15,2,7) 
send (scrn,1,5,0) 





2. The Receive Routine 
This procedure is the second and last routine which have direct contact with 
Operating svstem modules, specifically the Input Handler. It basically receives the 
message that was sent by the correspondent “send” routine, and since we are allowing 
variable message size, it returns to the user, as an output parameter, the length of the 


received message. It requires the following parameters: 
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e The channel id which is an integer value, multiple of 10, in the range of 50 up 
to 240. Much likely the “send”, we cannot use the operating system reserved 
channels, and with the “receive”, not even the “scrn” channel or ”40” is 
accepted; 


e This parameter is an output parameter of the type array, and contains the 
variable to hold the incoming message, which must be declared as an array of 
the same type of the original message; 


e The last parameter is also an output parameter and provides the user with the 
length of the message just received. It is included as a parameter, because we 
might have a case where the program must take an action based on the length 
of the message, but in most of the cases it can be disregarded. It must be 
declared as an array of integers with size 1. 


receive (VALUE channel.id, VAR message[ ],message.length[ ]) 


USAGE: receive (60,message.in,size) 





3. The Root Library (ROOT_LIB.TDS) 

This Library is intended to be used under the Operating System in the root 
transputer. It contains basically many I/O routines with various formatting capabilities, 
some conversion routines to change the representation of some data types, and some 
utilities which will help you in getting the real time inside some process, to calculate 
the transfer rate in KBits/sec of some link, to dump parts of memory for debugging 
muTposes, etc.... 

Unfortunately, the file system interface with the VAX/VMS is not supported 
by the OPS Kernel. in OCCAM1, and although we have put some effort in solving this 
problem, we didn’t have the sufficient time to get a successful result. This issue will be 
discussed later in the Section covering follow-on work, in Chapter VII. | 

The Appendix D will present the operating system for the root transputer, and 
in there, you will be able to find the filed fold ROOT_LIB.TDS, with all the routines in 
it. 

4. The Remote Library (REMOTE_LIB.TDS) 

The basic difference between both libraries is that in the first one, we can send 
anything directly to the screen, after receiving the consent of the Screen Handler, 
whereas in the second, we must always use the procedure “send”, by the special channel 


"40" or “scrn”. Another difference is that in the second library, we don’t have the 
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PROC rem.wnite.string, simply because the PROC send performs the same function, 
with even some more enhancements. Finally, we don’t have the PROCs rem.read. string 
and rem.read.number, which use the channel Keyboard for input. They were not 
implemented because of time constraints in our schedule, but we will give a brief 
suggestion for their implementation, 1n the Section covering “follow-on work”. 

Similarly, the REMOTE _OS.TDS which is presented in Appendix E, will 
contain the REMOTE_LIB.TDS as a filed fold. 
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V. EVALUATION OF THE OPERATING SYSTEM 


A. INTRODUCTION 

This Chapter will be devoted to one of the main issues, when dealing with 
programs which are supposed to run under a real time environment, and that is its 
“performance evaluation”. 

The evaluation will be basically software oriented, in the sense that no hardware 
measurements will be made. Strictly speaking, it will consist in running a special 
program, where all links will be exercised in transmitting messages of different sizes, 


and where the parallel operation of the links will be stressed as well. 


B. A BRIEF DESCRIPTION OF THE EVALUATION 

The configuration on which we are going to evaluate our operating system, is 
composed of a root transputer directly connected to four others transputers, as 
presented in Figure 5.1. The program used for the evaluation is a modification of the 
evaluation program made by Vanni J.F. in his thesis [Ref. 9], where a complete 
evaluation of the Transputer and its communications links is presented. We will be 
using even the same configuration, in such a way, that our final results for the link 
transfer rates, when using the Operating System, can be fully compared with his results. 

Basically, what his program does is to send successively to one transputer, then 
to two, three, four and finally to all transputers in parallel, messages with varying sizes, 
starting from 1 byte up to 10000 bytes.!® After receiving these messages the remote 
transputers will echo them back, also in a parallel fashion, and the root transputer after 
a very careful and precise timing process, will time the entire transfer process and 
display the transfer rate in KBits/sec. 

The structure of this evaluation program can be better understood, if stated as a 
sequence of steps, where each complete sequence will be applied, consecutively, for 
each message size. We will also present in Figure 5.2, a partial view of the evaluation 


program, which will be running in the root transputer. 


16In our modified version of his program, we will be lmited to a maximum 
message size of 4K, due to BOO] board memory limitations, which are aggravated by 
the fact that the Operating System must maintain a series of buffers in addition to the 
user declared ones. 
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Figure 5.1 The Configuration used in the Evaluation Process. 


A flag is sent from the root transputer to transputer #0. When the flag 1s 
accepted it will mean that the transputer #0 is ready to receive the actual 
message. The end of this step will determine the start of our timing process, 
which is carried out in the root transputer. The basic objective of this flag is to 
achieve the most accurate synchronization between processors as possible, since 
it will directly influence the precision of our results; 


The actual message is sent, and once it is received by transputer #0, we will 
stop timung; 


The transfer rate in KBits/sec is calculated and displayed as “LOUT"; 


Another flag is sent to transputer #0 for the same reasons specified in Step I. 
Once it 1s received by the transputer #0, we will start timing in the root 
transputer; 


The transputer #0 echoes back the message to the root transputer. Once the 
entire message is received the timing process is stopped; 


The transfer rate 1s calculated and displayed as “LIN’; 
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Zz). 


Two flags are sent in parallel to transputers #0 and #1. Upon arrival we start 
timing; 

The message is sent to both transputers, in parallel, by 2 different links. Upon 
arrival of both messages we stop timing; 

The transfer rate is calculated and displayed as "2O0UT"”; 


Two more flags are sent in parallel to transputers #0 and #1. Upon arrival we 
Start timing; 


The messages are echoed back by both transputers. Upon arrival of both 
messages in the root transputer, we stop timing; 


The transfer rate is calculated and displayed as “2IN”; 


Three flags are sent in parallel to transputers #0, #1 and #2. Upon arrival we 
start timing; 


The message is sent to the three transputers, in parallel, by 3 different links. 
Upon arrival of the messages we stop timing; 


The transfer rate is calculated and displayed as “30UT’; 


Three more flags are sent in parallel to transputers #0, #1 and #2. Upon arrival. 
we Start timing; 


The messages are echoed back bv the transputers. Upon arrival of all messages 
in the root transputer, we stop timing; 


The transfer rate is calculated and displayed as “3IN”; 

Four flags are sent in parallel to transputers #0, #1, #2 and #3. Upon arrival we 
Start timing; 

The message is sent to the four transputers in parallel by 4 different links. Upon 
arrival of the messages we stop timing; 

The transfer rate is calculated and displayed as “4OUT"; 


Four more flags are sent in parallel to transputers #0, #1, #2 and #3. Upon 
arrival we start timing; 


The messages are echoed back by the transputers. Upon arrival of all messages 
we stop timing; 

The transfer rate is calculated and displayed as “4IN’; 

Four flags are sent in parallel to transputers #0, #1, #2 and #3. Upon arrival we 
Start timing; 


The message is sent to the four transputers, in parallel, by 4 different links, and 
they will echo them back immediately. Upon return of the four messages at the 
root transputer, we will stop timing. This step is carried out just to check the 
performance when all 8 channels (2 per link), are working in parallel; 


The transfer rate is calculated and displayed as “4INOUT’; 
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PROC transfer = 
rae = [0 FOR nr.of.sizes] 


lock.size := sae aes 
-~- output to one channe 
AC Lucene cee ee = 
ae = [1 FOR repetition] 


send (90)0,"'a "i 

TIME ? timeO[0O 

send (90,0,buffer0,1,block.size) 

TINE 2 tamer yOys 

transfer.rate(time0[0],timel1[(0],1,bl 
etn See := ((actual.rate <9) 


ock.size, rate) 
) + rate)/j 


° 
° 
1°) 


-- input from one channel 

-- output to two channels 

-- input from two channels 
-- output to three channels 
-- input from three channels 
== QUCDUE COuroUm clamne lt. 
~- input from four channels 


° 
° 


-- all output and input in parallel 
actual rate y-— 0 a 
SEY j = [1 FOR repetition] 

EQ 


PAR 
send (90,0,"a ",1,1) 
send (100g ae 
send (tO, 2 "a ari: 
SENG Gl 20S) eye 

TIME ? timeQ([0Q] 

PAR 


send(90,0,buffer0d ,1 ,block-size) 
send( 1001 ,butferl b blec 7 size 
send(110,2,bufferZ,1l,block-size 
send(120,3,butfer3 ,1,block Jsaze 
recelve(50,buffer0,dummy0 
receive(60,bufferl,dummyl 
receive( 7/0 butter2, dummy Z 
receive(oo /burrers, aunmy, > 
TIME. 2 tamelo] . 
transfer.rate(time0{0],time1[{0],1,block.size,rate) 
actual.rate := ((actual.rate * (j=1)) + ratergg 





Figure 5.2 The Transfer Program in the Root Transputer (Partial). 
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Although this synchronization procedure through the use of flags is very accurate 
when using direct connections of links, that is not quite true when using the Operating 
System, and that is because we will be sending the flags, which are our time reference, 
through the same Operating System we want to evaluate. This latter uncertainty will 
have the effect of slightly decrease the actual measured transfer rate. Nevertheless, this 
is still the best way we found to get a sufficiently accurate result. 

Another point to mention, is that there will be a constant called “repetition”, 
which specifies the number of times to perform each of the above steps, in order to 


calculate an average value for the transfer rates. 


C. EXPERIMENTAL RESULTS 
1. Evaluating Direct Communications 

The tables must be interpreted according to the sequence of steps presented in 
Section A of this same Chapter. For example, if we look at Tables | and 2, we will see 
that when using one channel to output a message of 2048 bytes, we obtain a transfer 
rate of 3423 KBits/sec with the operating system, and a rate of 3658 KBits/sec without 
it, so that we can say we have lost 6% in the speed for this specific message size. Of 
course, this percentage tends to increase as we decrease the message size. In the most 
unfavorable situation, we will be trying to output and to receive a message of one byte, 
through the 8 channels, in which case we will have speed losses of the order of 96%. 
However, it is important to notice that we are comparing the operating system with the 
fastest available construct, which is the "BYTE.SLICE” [Ref. 9]. | 

As the reader can notice, the rates for the “INs” are somewhat higher than for 
the “OUTs”, but as the message size increases, they tend to equalize. We believe that 
the reason for that, is intimately related with the time spent by the synchronization 
flag, to pass through the operating system, and aggravated by the fact that the root 
transputer (1414-12) is a slower machine than the remote ones (T414-15). This extra 
overhead is expected to present a decreasing relative contribution, as the total transfer 
time goes up, which is a direct consequence of the message size. As one can see, this 
last assumption agrees with the fact that they tend to equalize. | 

Our next step in the evaluation process was towards the use of high priority 
for the operating system. As can be seen in Table 3, the rates for the “OUTs” have 
presented a modest increase, whereas the “INs” had a very substantial increase. 
However, as the reader can notice, the rates for “3IN” and “4IN” are not consistent, 


since we have smaller messages with higher rates than bigger ones, which is not correct. 
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We have no explanation for such a behavior, but we suppose that it might have some 
relation with the fact, that the user process, which has low priority, 1s accessing the 
send and the receive routines, which are high priority operating system routines. This, 
somehow, might be causing some sort of problem for the scheduler. However, 
although it was not checked, we believe that the data integrity was maintained, 
otherwise a deadlock would have occurred. 

After analyzing the experimental results, seems to us that the assignment of 
high priority to the operating system is the right way to go, despite of the problem 
presented in the previous paragraph. However, it is suggested additional investigation, 
before using the PRI PAR construct in the operating system. 

As a summary, we will present in Figure 5.3, a comparison between the best 


and the worst cases from Tables 1, 2 and 3. 


TABLE 1 


TRANSFER RATES WITHOUT THE OPERATING SYSTEM 
BETWEEN ADJACENT TRANSPUTERS*KBII3S/SE@ 


LIN 4INOUT 


616 
L239 





2. Evaluating Multiple Path Communications 
So far, we have been evaluating the operating system when working with 
adjacent transputers, which is not the most clever way of using it. However, when we 
have transputers not directly interconnected, which need to communicate among 


themselves, it becomes almost a must. 


ae: 


TABLE 2 


TRANSFER RATES WITH THE OPERATING SYSTEM 
BETWEEN ADJACENT TRANSPUTERS (KBITS/SEC) 


TABLE 3 


TRANSFER RATES WITH THE OPERATING SYSTEM (HIGH PRI) ° 
BETWEEN ADJACENT TRANSPUTERS (KBITS/SEC) 


2IN 
Lot 





In this subsection, we are going to evaluate the performance of the operating 
system for a multiple path communication, or sometimes referred as multiple hops 
communication. The tables 4, 5 and 6 present the transfer rates for 1, 2 and 3 


retransmissions, which actually corresponds to 2, 3 and 4 hops, respectively. It is 
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worth mentioning, that the retransmission process is not a strict key switching, where 
the “link transputer” would have just to connect its input to the output links directly, 
and that is it. Actually, each transputer in order to retransmit a message, should have 
to receive and store the entire incoming message into its local memory, and only then, 
start the retransmission process. That is basically what is going to be evaluated in this 
Section. 

The program will be basically the same, with a slightly modification in the 
routing table. For the one retransmission case (2 hops), we have forced the transputer 
0 to send its messages to the root transputer, via transputer 2. For the 3 hops case, via 
transputers 2 and 1, and finally, for the 4 hops case, via transputers 2, | and 3. 

However, it is important to mention that the transputers which are going to 
be used as “links” are overloaded, since they are still sending their own messages as 
well. Hence, this evaluation is going to be a sort of “worst case” evaluation. It 1s 
believed, that if the other processors were not executing any processes other than the 
Operating system, these transfer rates would have presented a substantial increase. 
When examining these tables, notice that the “OUTs” are about the same as in Table 
2, with adjacents transputers, and that happens because the root transputer is still 
sending the messages directly. Therefore, only the “IN” columns will be of interest, in 


this step of the evaluation. See in Figure 5.4 a comparison between Tables 4, 5 and 6. 


TABLE 4 


TRANSFER RATES WITH THE OPERATING SYSTEM 
tenOPs (K BITS/SEC) 
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TRANSFER RATES WITH THE OPERATING SYSTEM 
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TABLE 6 


TRANSFER RATES WhlH THE OPERATING Sis Gea 
IN 4 HOPS (KBITS/SEC) 


BYTES 10UT IRA) Z0UT ZIN 30UT 3IN 40UT 41IN 4INOUT 


Z Zi “) 9 5 6 6 5 4 2 

Z 43 re ibs, ike ies ibs 10 g 6 

4 65 S6 38 38 agi 26 75 18 iz 

8 166 70 i> 2 58 50 42 36 25 

16 Ss ey 147 1S) 106 35 83 69 49 
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D. EFFECT OF THE HEADER SIZE IN THE TRANSFER RATE 
One of our main concerns in the design phase of the communications protocol, 
was regarding the size of the header. We thought that decreasing the header size by © 


half, for example, we would almost double the performance, mainly when dealing with 
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Figure 5.4 Transfer Rates with Multiple Retransmissions. 
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MESSAGE SIZE (BYTES) 


small messages. However, as can be seen in Table 7 and Figure 5.5, the effect of the 
header size was found to be minimum for all message sizes. In the worst case, we 
cannot even notice any difference at all. 

The new protocol we will be testing, will have a header which is 3 bytes!’ long, 
and the only difference from the previous one, is that the message size information will 
take up one byte, rather than two. Therefore, we will be limited to messages up teizee 


bytes. 


TABLE Ly 


TRANSFER RATES WITH THE NEW HEADER 
BETWEEN ADJACENT TRANSPUTE RSA RBS ie 


BYles eL0ur LIN ZOUT 2IN Sour 3IN 40UT 4IN 4INOUT 
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E. A CONTROVERSIAL PROBLEM 

In the first version of our evaluation program, we were using the remote 
transputers, which are T414 (15 Mhz), to send the synchronization flags to the root 
transputer, which is a T414 (12.5 MHz). We had chosen this way because we would be 
able to start timing only after the flag had passed through the operating system, 
resulting in a more accurate timing. 

However, after a period of approximately 16 seconds the program was 
deadlocking in a random state. and bear in mind that within this time, we were able to 
perform up to 9 complete runs of the same program ! Another symptom was that 
before deadlocking, we could notice a very big increase in the transfer rates of the 
LING. 


l7\We have chosen the new header size to be 3 bytes long, because in doing so, 
we wouldn't have to make major changes in the protocol design. 
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Figure 5.5 Effect of the Header Size in the Transfer Rate. 
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The reasons for such a behavior are stil] unknown, but we found it would be 


useful to pass this information, since it may happen again, in some other experiment. 
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VI. USING THE OPERATING SYSTEM 


A. INTRODUCTION 

This Chapter will introduce the operating system under the user’s point of view. 
Our system is intended to be used in any transputer network, but when dealing with 
very small networks, up to 5 transputers, where we can always find a direct 
communication path between them, it may be a better choice not using the whole 
Operating system, but just its library routines, mainly when dealing with small messages 
and when efficiency is a critical issue. However, in all other cases we strongly suggest 
its use, so that the debugging capability of the distributed system will be extremely 


enhanced, as well as the ease of programming. 


B. THE REQUIRED PROGRAM STRUCTURE ° 
The very first steps are basically the same for programs with or without the_ 
operating system, and they are: 


1. Divide the entire program into modules, which can be run in separate 
processors. Ultimately, these modules will become SCs to be placed in our 
configuration. 


2. Specify the interfaces between modules (or SCs) and make a sketch of the 
desired configuration. 


Now it is time to change a little bit the structure of the TDS program, as 
mresented in Chapter IT. 

The new structure is the one presented in Figure 6.1, where some comments are 
required for a better understanding. 

AS one can see, what we need to do is to create a filed fold containing either the 
root or the remote operating system source code,!8 in each of the SCs, and run the 
user process in parallel with the operating system. As discussed in the previous 
Chapter, the PRI PAR construct should be more efficient, but we suggest to develop 
the entire program with no priority assignments, leaving them for the very end. 

Another peculiarity is the new parameters list which must be passed in the 
configuration part. The channels parameters have been extensively discussed in 


Chapter II, when we were talking about configuration, so that at this time, we will skip 


l8They are contained in the files ROOT _OS.TDS and REMOTE_OS.TDS 
respectively. 


81 


SC PROC transputer.root (CHAN A,B,C,D,E,F,G,H, 
VALUE this. trans uter, 

tO; tl, tZ, Gore tS ,t6, 

t7,t8,t9,ti0,ti1,t12 

t13,t14,t15,ti6,t17 } 


7h = ROOLSO5. 205 
ee PROC user.root 
PAR 


ope hab sie oY Scan 
user.root: 


SC FROG Eransputern.. (CHAN A,B,C,D,E,F,G,H, 
VALUE this. trans uter, 
CO” El.t2 ts eee t5,t6, 
tT € '£9°t10,t11,t12 
t13,ti4,t15,t16,t17 } 
oes IREMOnE OS. b> 
oe PROC user.1l 
PAR 


operating.system 
uS6Y oi: 


- SC PROC transputer. 2 (CHAN ApBr C.D Er yGeae 
VALUE this. trans uter, 
LO el Eee -t4,t5,té, 
t7,t8,t9,t10,til,ti2 
t13,t14,t15,t16,t17 } 
sf REMOTE OS.1DS 
woes PROC user.2Z 
PAR 


operating.system 
user.2Z: 


SC PROC transputer.n (CHAN A,B,C,D,E,F,G,H, 
VALUE this.trans uter, 
tO, tl, t2,t3,t4,t5,té6, 
t7.t8,t9,t10,til,ti2 
t13,t14,¢15,t16,t17 3 
sf), REMOTE (OS.1Ds 
ae PROC user.n 
PAR 


operating.system 
user.n: 


eOntaguraeron 





Figure 6.1 The Program Structure when using the Operating System. 


them. ihe next parameter 10. be passed is the transputer id number of that specific 
transputer. This id number will be used as an index in the routing table, to find the 
output link to some message. It must be in the range of O to 17, since our actual 
implementation of the routing table has only 18 entries. Another suggestion is to use 


the same number used in the configuration, although it is not mandatory. 
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Finally, the last 18 parameters are the routing table itself, which was already 
extensively discussed in a previous Section in Chapter IV. The reason we are passing 
value by value, is just because OCCAM1 does not support TABLE data type as a 
parameter in the configuration. It is believed that this problem has been overcome in 
OCCAM2?. 

The user “cannot” change the names of the parameters this.transputer and tO up 
to tl7, since they will be passed as predefined global constants to the Operating 


System. These names must be the same for all SCs in the entire program. 


C. PROGRAMMING WITH THE OPERATING SYSTEM 
The art of programming a distributed system is usually done by lead 
programmers, with a great knowledge of the architecture they are working with. 
However, in our case, with the aid of the operating system, this task will be so much 
simplified, that it will be possible to an applications programmer to carry out this job. 
However, as in any operating system, there are some peculiarities, which must be 
known by the user, before he starts to use it, and in our case they are the following: 


e Whenever we want to communicate with external transputers we must use the 
“send” or “receive” routines. We also maintain in our Library a series of I/O 
routines and some utilities, which make use of the send routine and must be 
used only if we want to have some kind of output to the screen. Therefore, 
when using these library routines, we must always have the root transputer as 
our final destination. 


e The user must have a complete knowledge, of the available library routines for 
the root, and for a remote transputer as well. We have tried to keep the same 
names for the procedures in both libraries, just adding a “rem” in front of the 
Original name, if it was to be used in a remote transputer. The onlv exception 
was the “write.string”, which was taken out from the remote library, since the 
“send” routine performs the same task, with even some more enhancements. 


e If for some reason, none of the library routines fits our needs, we can still 
remotely access the screen, by using the “send” with the special channel “40” or 


” 


scm . 


¢ In the actual implementation, the valid channel ids are multiples. of 10, starting 
from 50 up to 240. 


e [tis very important to keep in mind that for every “send” operation, must exist 
a matched “receive”, with the same channel id number, and in the same 
destination transputer of the “send”. 


As one can see, there is no difficulty in programming with the operating system. 


In very few words, what needs to be done, is nothing else than a standard uniprocessor 
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program, and wherever we need some sort of external communication, either to the 
screen, or to any other transputer, we just have to follow the previous rules. As an 
example, we will provide in Appendix F, a complete listing of the evaluation program, 
which was running under the Operating System. In this program we make very little 
use of the various library routines available for remote transputers, but the main idea is 


just to show the overall structure of a program running under the Operating System. 


D. ADVANTAGES OF THE OPERATING SYSTEM 
We will now provide a list, with some of the main benefits, originated from the 
use of this operating system: 


1) We can have as many as needed “send” or “receive” calls inside a parallel 
construct. The various “send” could be even for the same transputer, in which 
case, the operating system would take care of multiplexing them, through the 
correct output link. The onlv requirement is that all the channel ids in each of 
the send inside a parallel construct must be different. 


2) Now we have the capability of debugging remote transputers. For example, we 
can send a unique flag to the screen when entering or exiting every procedure 
running in some remote transputer, so that we could obtain a complete trace 
of our program, and even determine where the system was deadlocking, if that 
was the case. 


3) Thanks to the remote dump routine we can now dump the entire memory of 
any transputer in the network. 


4) With the remote I/O routines, we have got formatting capability, so that we 
could have, for example, transputer | using the upper left part of the screen, 
transputer #2 using the middle part, transputer #3 the lower nght part, and so 
forth. 


E. CUSTOMIZING THE OPERATING SYSTEM 

This Section describes which set up must be performed, prior to the use of this 
Operating svstem with some user program. 

There is a fold called “Operating System Global Declarations”, which is the only 
place, where the user should perform any sort of change in the O.S. file. However, 
there are some declarations and definitions in there, which just need to be modified for 
maintenance purposes, done by qualified people. 

In most cases, the only definition we will need to change is the “max.block.size’, 
which specifies the size, in bytes, of the lengthiest message to be accepted in that 


network. 
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VII. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

This thesis is a first effort in developing an Operating System for a distributed 
system of transputers. .I[t was built from three basic modules, namely, Input Handler, 
Output Handler and Screen Handler, which were implemented under severe efficiency 
requirements. 

In order to achieve this basic requirement, we had to avoid moving data inside 
Our system, as much as we could. A close look at the code will confirm, that most of 
the processing time is spent in exchanging flags among the different modules inside the 
Operating system. Even the flags were checked for efficiency, in other words, the type 
of flag we are using is proved to be the fastest one in that regard. As the reader can 
notice, most of the flags and I/O are implemented with the BYTE.SLICE construct, 
which has been proved to be the fastest construct available in the transputer [Ref. 9]. 
Only in the alternate construct we keep the standard OCCAM I/O channels, because 
the “ALT” does not accept the BYTE.SLICE as a valid guard channel. 

Now, as we may recall from Chapter V, the performance figures of the operating 
system, demonstrates that it is quite efficient, mainly for messages bigger than 2048 
bytes. At this size for example, we have losses ranging from 8% up to 25%, depending 
on the number of channels, which are transmitting and receiving in parallel. !? The last 
value was obtained when the 4 channels were transmitting and receiving in parallel. 

As far as debugging goes, the operating system was very successful, in the sense 
that it brought up a new perspective in this field, for a distributed system of 
transputers. Although we realize that it 1s still far from being ideal, we should agree 
that it provides the user with some capabilities, which were not easily achieved up to 
now. 

The other main goal to be achieved by this thesis, is regarding the ease of 
programming a distributed system of transputers. Now, anyone would be able to very 


quickly, make a program to be run in a very large transputer network. 


This figures can be increased, mainly when dealing with smaller messages, if we 
decide to use the operating system in high priority, as depicted in Chapter V (Table 3). 
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Returning to the efficiency issue, which is one of the major concerns in real time, 
we strongly believe that if the present trend of increasing transmission speed continues, 
we will be reaching a point where no more shared memory will be needed, since the 
link speeds will be sufficient high, to allow the transmission of the global shared data 
to all users of it. Let us put some numbers in this previous assumption. Assuming that 
the new family of transputers, the T-800's, will really support a truly 30 MBits/sec for 
the link transmission speed, we will be able to achieve with our basic operating system, 
after 4 retransmissions, and also considering the worst case (4INOUT), rates of the 
order of 5 MBits/sec, which is a fairly high rate. 

Two conclusions can arise from the preliminary results. First, a real time 
Operating system for a network of transputers is feasible and highly recommended. 
Second, the shared memory architecture seems to be no longer the preferable 
architecture for sharing global data, since we are going to be able to achieve 
comparable results, without the disadvantages of having shared memory, like for 
example, the system bus constituting a single point of failure. 

Therefore, the transputer appears to be an attractive architecture for 


implementing real time applications, where the reliability is a fundamental issue. 


B. RECOMMENDED FOLLOW-ON WORK 

As stated in Chapter I, this thesis is a first approach to a basic operating system 
for a network of transputers, and it is our hope that it serves as a firm foundation for 
future and more enhanced implementations. 

As this thesis was being developed, many new ideas were brought up, and in this 
Section we will try to give some suggestions for future enhancements in the svstem: 


e Conversion of all programs used in this thesis to OCCAM?2. It is also 
important, to reevaluate this new version of the operating svstem. 


e Implementation of some filer routines which would allow one to open, close, 
read and write to VMS files. However, it is believed that OCCAM?2 provides 
already this capability. 


e Creation of one more reserved channel in the Operating System, which could 
handle inputs from the keyboard to remote transputers, with a minimum 
interference in the process running in the root transputer. The suggestion 1s to 
make up a simple protocol for entering data from the keyboard, for example, 
always entering with the destination transputer id# first, followed bv a carriage 
return, and only then, we should enter with the actual input data. The next step 
should be to change the procedure “read”, which is inside the terminal driver, 
and insert a check for the transputer id#. If after checking, it was found to be 
for a remote transputer, we should send the incoming message directly to the 
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remote transputer, through a new reserved channel, in such a way, that the 
remote transputer would be able to recognize that the message was carrying 
some keyboard input data. 


Implementation of an adaptive routing to replace the present one, which 1s 
Static. This feature could be further extended, in order to generate a complete 
fault tolerant system. OCCAM2 provides some built-in procedures like 
“OutputorFail”, InputorFail” and “Reinitialise’, which might be very helpful in 
solving this problem [Ref. 11]. 


Construction of a more powerful set of Library Routines for the root and 
remote transputers, e.g. concatenation... 


Make the Operating System resident in the transputers, in other words, when 
we turn the power on, it should be automatically loaded into all transputers. To 
accomplish this step we would need to change the loader program, which 
resides in the EPROM of the BOO1 board. 


Construction of a more powerful debugger. However, it is not imperative, in 
our understanding, to make a debugger with multiprocessor capability, since we 
can always map our program to run into a single transputer. In order to 
implement a debugger, we would have to make it resident in the upper part of 
memory, and we would also need to have some kind of deassembler, in order to 
correctly place the breakpoints inside the code. 


Enhancement of the Terminal Driver by changing its I/O handling. Presently, it 
1s implemented by standard OCCAM 1/O channels, so, the idea is to use the 
BYTE.SLICE, which 1s a much faster construct. However, keep in mind in mind 
that the single character will have to be handled as a special case, since the 
BYTE.SLICE only supports byte arrays. 
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APPENDIX A 
OPS GLOBAL DEFINITIONS (GLOBAL_DEF.OPS) 


tobaledesr ao 

onstant De salam 
DEF ort = : --- assigns the RS232 port to the terminal 
DEF baud = 11: --- set baud rate to o00sue- 
DEF nul = 0: === null asc eaane 
DEF bell = 7; “<= Deu dsc ieee 
DEF tab = 9: --- tab ascii value (every 8 col) 
Dene. & = 10: ==— litteteed@easci ie cic 
DENeer = 13: --- Carriage retunn casei. yauwe 
DEF esc = 27: --= escape aseii value 
DEF sp = 32: --- space ascii value 


-- Channel peer a eat eee 


CHAN Parameters AT 0 

CHAN Screen AT 1: 
CHAN Keyboard AT 2: 
CHAN FileinO AT 3: 
CHAN Fileinl AT 4 : 
CHAN Filein2 BT 52°: 
CHAN Filein3 AT 6: 
CHAN Filein4 AT 7: 
CHAN Fileins AT 8: 
CHAN Filein6d AT 9: 
CHAN Filein?7 AT 10 : 
CHAN Fileouto AT 11 : 
CHAN Fileoutl AT de: 
CHAN Fileout2 AT 13 : 
CHAN Fileout3 AT 14 : 
CHAN Fileout4 AT 15 : 
CHAN Fileouts5 AT 16 : 
CHAN Fileout6 AT 17 : 
CHAN Fileout?7 AT 18 : 


-- Link Definitions 
DEF linkOout : 
DEF linklout 
DEF link2out 
DEF link3out 
DEF linkOin 
DEF linklin 
DEF link2in 
DEF link3in 


-- File Handler en a. 


WITH OB GNF © 


DEF ClosedOK = -] 
DEF CloseFile = -2 
DEF EndBuffer = -3 
DEF EndFile = <4 
DEF EndName = <5 
DEF EndParameterString = <6 
DEF EndRecord = -7 
DEF NextRecord = <9 
DEF OpenedoK = -10 
Dae Opensorkeaa = -11 
DEF OpenForWrite = -1l2 
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-- File Handler Error Values 


DEF FileNameTooLong = #80000000 
DEF InputFileNotOpened = #80000001 
DEF OutputFileNotCreated = #80000002 
DEF InputRecordTooLong = #80000004 
DEF ReadFailed = #80000008 
DEF Poe ea eo nanookeng = #80000010 
DEF WriteFailed = #80000020 
DEF CloseFailed = #80000040 
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APPENDIX B 
TDS GLOBAL DEFINITIONS (GLOBAL_DEF.TDS) 


-- global_def.tds 
-- Constant sees eel 


DEHRDOnE = : --- assigns the RS232 port to the terminal 
DEF baud = 11: === set baudinate ton Joet@eps 

DER nul = 0: --- null ascii value 

DEF bell = 7: --- bell ascii value 

DEF tab =9; --- tab ascii value (every 8 cod) 
DER Lt = 10: --- linefeed ascii value 

DER cr = 13; === Gabriagdeshettnn dcetre va rue 
DEF esc = 27: --- escape ascii value 

DEF sp = 32: --- space ascii value 

-- Channel Decnorseacus 

CHAN Screen 


CHAN Keyboard 


-- Link cess Lease 
DEF linkOout 
DEF linklout 
DEF linkZout 
DEF link3out 
DEF Sano 
DEF linklin 
DEF link2in 
DEF link3in 


uuu ud wet 
“OO BWNME O 
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APPENDIX C 


TDS LIBRARY ROUTINES WITHOUT OPERATING SYSTEM 
(LIBRARY.TDS) 


mam KKKKKKRKRKKKKRRRKKRRRRRRRRREKRERKRRRRKRKRRRRKKRRKRRRRRRRERRRREK 


~—— Title: LIBRARY.TDS Avie tGorOn sl. Ous- 
sss Author: MAURICIO DE MENEZES CORDEIRO * Mod: 0 a 
-<-- Date: 19/FEB/1987 KREKKKKKKKKRKKKRKARKK 
sm a Programming peneua gen OCCAM 1 i 
--- Compiler: “IMS D-600 (VAX/VMS) a 


Brief Be Lay This Bnogean contains some library* 
FowUtines to be used in any TDS program, when not cS 
SS Operating System. It must be placed in = 


t 
t 
t 
YD A SS i SM, SS a a SS Se 


“== parallel with the user process and with the global %* 

definitions for TDS. ae 
me KAKAKKEKAKKAKKKAKAAKRAAAKKAARKAKKRKAKAKKARARARARRARRARRRRKKR 
=== Mod #: | Date: * 
~2e Responsible: | * 
—— Brtef. Deseripition: : 
mae KAKAAKKAAKAAKAKKAKKKKKAAKAKKAKKRKARKAKRKKK RRA AKA AKAAKRAARAAKKA 
==5 Mod #: — Date: * 
225 Responsible: | z 
ma | Deter Deson ep ulon: if 


mame KKKKKKKKKKRKRKARRKRKRRKRKRRKRRKRKRRRKRKRKRKARKARKRRRRRRRRRRKRRRREKRRRRRERRRRE 


-- io_routines 
== PROC dec. to,hex (VALUE integer, VAR string[]) 
mane KAKRARKAKAKKKARKAAKRAKKKAKRRRAKRRAREAKRRARR KKRAKKKARKAKKR 
--- DESCRIPTION: It converts an integer number from its 
Gegececiinal representation into the equivalent hexadecimal ~* 
eagmone. it accepts any valid integer. It returns the * 
=== hexadecimal number stored in a string of 10 bytes long * 
--- where the leading zeros are preserved. * 
--- It returns the following format: [size]#0000FFFF * 
--- USAGE: dec. to.hex(37182,hex.string) | * 
=== REMARK: The BYTE[QO] of the string carries its length e 
--- which is always 9, therefore it could be deleted, but a 
* 


--- we decided to keep it. 
wm KKKKKKKKKKKKKKAKKKKKEKKKKKKARAREKRARKRKRRRKERRERKRKRRKRKRAKKKRE 


PROC dec.to.hex (VALUE integer, VAR string []) = 
Permcirst, Order.of.digit, digit : 
VAR number : 
aa hex.char = "0123456789ABCDEF" 

irst := TRUE 
string ee 7 
sting | BYrE 1 
number := integer 
order.of.digit := 9 
WHILE (number > 0) OR (first=TRUE) 


SE 
digit := number /\ #F 
aiciiee= hexschar |BYIE digit + 1] 
Stbing (BYTE order.of.digit] := digit 
number := number >> 4 
Srdenwon.digit := Order.of.digit = 1 
Phe. aon 

SEQ i = [2 FOR (order.of.digit - 1)] 
String [BYTE 1] ;= '0'; 


9 
re 


-- PROC dec.to.ascii (VALUE integer, VAR string []) 


mil 


KAKRAKKKKKKKKKKKKRKRKKRKKRKRKKRKKAKKKKRKRKKRRRKRKKRKAKAKRKKKRKRRRKRKRKRKAAKKKK 


DESCRIPTION: It converts an integer number from its 
decimal representation into the equivalent ASGihecme ar 
accepts any valid integer number. It returns the ASCIT 


number stored ina Sed 
number is right justifie 


a. 
1322 


format: 


42 
<)8y7: 


---> 
---> 


of 12 bytes nope where the 
bee ig 


and 
{1 


ond 
If 
| 


PIPE MQei* gr iar igri |zr0tr7 


USAGE: dec.to.ascii(-9873,ascii.string) 


REMARK: The BYTE[O] of the string carries its length 
which is always 11, therefore it could be eliminacedaeue 


we decided t 


Le: 
KRAKAKKKKKKKRAKKRKKRKKRKKAKKAKKKKKKKKKKKKAKKKKKKKKKKKKKKKKKKK 


o kee 


lowin 
15! 


613i Parig 


> 


* 


PROC dec.to.ascii (VALUE integer, VAR string []) = 


VAR numb 


Cr 


VAR order.of.digit : 
- 2147483648 


DEF min.int 


SEQ 


= 
° = 


number in 
Order Of dig 
string [BYTE 
SES 


number 


numb 
Sic 


Leger 
ae 
0] 


Care 


BYTE 
BYTE 
BYTE 
BYTE 
BYTE 
BYTE 
BYTE 
IBYTE 
[BYTE 
BYTE 
eee 


string 
string 


order.c 


eracn0 
Q 

number 
string 


:= ll 


ninunnunhnoown 


hm CK 
a a | 


Bite t 
epee sd 


[BITE 1 


n 
[BYTE 1 


string [BYTE 1] 
-- building up the actual number 
WHILE number > 0 


SE 


number 


SEQ i 


°° —_ 
e 


limit case 


ead 
Bo! 
Bale 
igi 
17! 
igi 
18! 
13! 
6! 
se 
18! 


Hy 


ie 


‘=_ t 


14 
1o! 
10 


Q 

StrING 1 BYle “Order: ofacacnae 
:= (number 
Order.0L clgLe 


=" | error 
string [BYie 2} 


/ 10) joa 
order.o£, digit. = 


--- number > 0 


(number \ 10) + '0! 


order.of.digit - 1)]) 


-- PROC hex.to.dec (VALUE string[ | VAR integer OK) 
KRAKKKAARAKAKK KAKA AARARKKAKAARARAAKKARKAKARR RRRAKKRARARKAKRARKK 
DESCRIPTION Tr BSceR Esra hexadecimal representation of * 

a number and converts 1 into an antegern ninco maee * 
expects scene pase of the string to carry the size * 
information of that "hex number". nS 
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--- USAGE: hex.to.dec ("#00003785", number ,valid) x 
--- hex.to.dec ("#1452"', number valid) zk 
o- hex. to.dec WHIQ574 number ,valid) x 
ee ascii.to.dec (hex.string, number ,valid) *s 
--- REMARK: Seu a boolean value FALSE in OK if the * 
--- string is not in the correct format. * 
mam KKAKK SRA A RI ARASH RI ERI TRI RII RII ARIAS I ARR AI RAIA RI 


PROC hex.to.dec (VALUE string [], VAR integer, OK) = 
SE 
integer := 0 
LF 


-- empty strin 
Soa [BYTE 0 = 0 
:= FALS 


== eNews numoer 
ecEeug (BYE -O | <0 


-- starts with ae 
string [BYTE 1] = '#! 
VAR Count 


SEQ 
OK := TRUE 
Count := 2 
WHILE (Count <= string [BYTE 0]) AND OK 
VARS Di gic: 


DEF hexChars = "0123456789ABCDEF" 
IF 


\] 
BYTE Index] = string [BYTE Count] 


IF Index = te FOR hexChars [BYTE 0 
- hexChars 
Digate:= "index - 1 
TRUE 
7 FALSE ay 
placer := (integer << 4) + Digit 
:= Count + 1 


Coun 


-- otherwise 
String (BYTE 1] <> '#! 


OK := FALSE 
SKIP 
== PROC ascii.to.dec (VALUE string| | VAR integ K) 
wan KKKKKARKAKKKKAKKKKKRKKKKKARKKKER EP ree ease ee ans KKRKKKKKKE 


--- REMARK: Returns a boolean value FALSE OK rt the 


4. 16) See Ae On OAC en re Ce mC ne Mm SEC Ne lt. yn cles el ee 


See DOOCRIPTION: It accepts an ascii decimal * 
mee oe DS pleat GapaeianiDenheandsecenvercts TE Anto an 3 
--- eger number. It expects the byte[0] of the Sea “s 
Beeeco carry the size information of that “ascii number ‘ 
SeeeUOAGEh: ascii.to.dec ("-3785" number,valid ia 
——- ascii.to.dec ("+1452" number,valid x 
--- asciuetomdecs( 19574". ynumber,valid * 
= ascli.to.dec (string, number valid) 5 

x 

* 

x 


gg ests. to.dec (VALUE string [], VAR integer, OK) = 
moeeger := 0 
IF 


~~ empty strin 
g 1B 


ect sng YTERO| = 0 
FALSE 


== numbe 
string [BYTE ois 0 
VAR Sign 
VAR Start 
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VAR Length 
SEQ 
OK := TRUE 
IF 


=> negaeave 
string (BYTE) f= 
SE 


ign := - 1 
Soda = 2 
Length := string [BYTE 0] - 1 


-- positive 
String [SvIEB oe 
SEQ. 
zon s=91 
start ;:= 1 . 
Length := string [BYTE 0] 


-- convert to integer 
Senor ae [Start FOR Length] 


Re Sa Gites 
SEQ, 
pet := string [BYTE Index] 
('Q' <= Digit) AND (Digit <= '9') — 
integer := (integer * 10) + (Digit -so") 
TRUE 
OK := FALSE 
integer := integer * Sign 


SKIP 


=> PROC Wri tewserinc (VALUE string[]) 

mm KRKKKAAK KA RAK KAR KRAKK ARK KK KKK RRR RKKK KK RARER RRA RAK KR RAKE 
=—— DESCRUP PION  Wortes a Saver string to the screen, ina 
=== byte by byte fashion. Lt requines that the sen ncaa. 
]“== 18 a byte array, provides the size of tne sscmiigqmenedes 
= Dy Ee o1, otherwise we will get unpredictable results. We 
=== are limited to Strings Up ute 255) characters smucm bigger 
2am Dy cerauraycy Ot stone orien printing use 'send.string”. 
--- USAGE: Be eed "Hello!') 


~~~ REMARK: It does not provide an automatic cr,lf. 
mm RARKAKARARKAKARAKKA KKK ARK KAKKK KK AKA AKRERKKARAKRK RAK AKAARAK 


pa a a a a Ss Sa 


PROC write.string (VALUE string[]) = 


Sa 
350 1= [1 FOR StringiSyioo| 
screen ! Strang Byrn. 
Sate. 


== PROG write. string. fast (VALUE string[])} 
mn KAKKKAKAKAKKKAKRRAAKKKAAARKAKKRKARR KRAAKKRKAKKAAAKRRAAR 
--- DESCRIPTION: This procedure works just in TDS and speeds * 
--- up things since the whole block is scheduled by CPU just * 
--- once, unlikely in the PROC write.string where each byte * 
--- is individually scheduled. However the terminal driver ~*~ 
--- routine MUST BE changed prior to the use of this routine.* 
x 
* 


-~- USAGE: write. string. fast (string) 
man RAKKKAAKAKKKAKAKAKKEAKAKKARKAKARK KR AKRAKKKKKKAKKAKRKK AK RARRK AK 


BERGE Write.string.fast (VALUE string[])= 
BYTE.SLICE.OUITPUT (Screen,string,1,string| SYioeomer 


-- PROC write.number (VALUE integer) 
mmm KKKKKKKKKAKKKKRKKKKKREKIK RAR RIKKI KARA KKK RAI KARR ARKIN 


--- DESCRIPTION: This PROC outputs a signed integer value to * 
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--- the screen. It left justifies the number, so that if you * 
--- need it right justified, use the dec.to.ascil and then %* 
acne NS deka ea routines. os 
--- It uses the following Bouma ; : 
---> 

--- -234193 ---> -234193 * 
aa . 1496 ---> 149 i 
--~ USAGE: write.number (integer) fi 
* 


write number (135) 
mm KKKKKKKKKAKKKKAKAAKRAAARRRARKRAKERRRERAEKRRKEKREKRKAKAKREKRKRERER 


PROC write.number(VALUE integer) = 
DEF min.int = - 2147483648 : 
DEF max.digits = 11 
VAR number : | 
VAR order.of.digit : 
VAR digit [BYTE 12] 


SEQ | 
number := integer 
pace + Ca := 11 
I 


number = min.int 


ae 
TF 
number < Q 
SEQ 
number := - number 
Screen ! '-! 
TRUE --- number > 0 
SKIP 


WHILE number > 0O 


SE 
digit (Bitbeoncerheor.digit|] := (number \ 10) + '0' 
number := (number / 10) eo 
Spee @eot dtame— Onder.g:.digit — 1 _. a 
BEY ie (Onder onsd2q1e + 1) FOR (max.digits=-order.of.digit) J 
pe Picco 1 | 


-~ PROC read.string (VAR string[])} 

mame KKKKAKKAAKKKAKARAKKKAARRAKRRAARAARRAAKKKAKRKKARERKRRARRARRAARK 
-~-- DESCRIPTION: Reads any input sequence of characters typed* 
geeectom the Keyboard and stores them in a string, while 
Seemecnoing them to the screen. The PROC is exited when a 
Seco € 61S typed. 

=== USAGE: read.strin Weer ice cee . 

= lad peek: ys byte[o carries the size information of the 
Seeeotring. 

sSe REMARR? Although it accepts strings of any length, the 
e-- size contained in byte[0] will be reliable only for 

—- Beano WeecOnZos OY TES, 

--- REMARK3: To enter with strings bigger than 80 bytes use 
Samecne Lf ney Digl whale: atenilorer Jatel e . 

--- REMARK4: The set up of your cr key in your keyboard will 
Seeececermine where the cursor will be at the end of the 


i i NM i SM SN 


BOUEInNe. 
wm me  KKKKKKKKKRKEKKKRKAKRKKKAKKKAKKKKKKKKKRKKEREKKERKKEKKKKKKREKRRKEKKEKEKE 


PROC read.string (VAR strin ) = 
VAR n, char ay at 


char := 'z'! 


n := 0 
WHILE char <> cr 


Shs: 


SE 
Rogues ? char 
Screen ! char 


nos] net 
sees 82 n}] := char 
Screen ! 


String[BYTE 0] :=n: 


~- PROC read.number (VAR number) 
wae KRAKKKKAKKKAKKAKAKKKKARKKRARKAKKAKKKKKARKEAAKAKKAKKARKKARKKRKA 


~-- DESCRIPTION This procedure reads a number as entered from* 


--- the keyboard. It accepts the following entries format: 
ae 45560022 5-cr-> 
--- +37 Oc s<Gr> 
“~~ =67 2405 <Gr> 


~-~- USAGE: read.number (into.integer) 

--- REMARK1: Only valid inputs will be echoed to the screen, 
“== sO if yOu enter with =24r5e6, the following svi 

--- eupeay in the screen: -3456 meaning that the number 
-3456 was accepted. 

s=- REMARK2Z: This procedure does not check to seeuieuene 

Ba Stn lacs ai gies than MAXINT or smaller than MININT. If 
-~- that happens the result will be incorrect. 


--~- REMARK3: An automatic cr,1lf is provided when exiting. 
we KARAKAKAKAAAAAAKKAKARARAKARKKKRKR AKA RARARERARARARARRREKKR 


> a a SS 


PROC read.number(VAR number) = 
VAR Chas | 
VAR negative 


number := Q 
negative := FALSE 

WHILE (ch <> '=-') AND (ch <> '+') AND ((ch < '0*) OR (eh > oie 
rumcede 7 Cn 


negative := TRUE 
Screen ! ch 


SKIP 
WHEGE Cen <> cr 


SE 
CHILE (ch <> cr) AND ((ch < '@') OR ch =o 
Keyboard ? ch 
number := ( number * 10 ) + ( ch - '0' ) 
Screen ! ch 
Keyboard ? ch 
Shr 
Screen ! lf 
IF 


negative 
number := - number 


-~- PROC clear.screen 
wee we KK KKK KKKKAKKKKEARAKAK RAK KAKAK KAKA KK AK KKK RAK KKKKAKKAKAKKAKK 


-~- DESCRIPTION: It clears the screen and homes the cursor. % 


=<-- USAGE: clear.screen 
we wm RK KKK K KKK REKKKK KKK RARE AK KARR KKKK KA KAKKAKKKKAKKKARKKA KEK 


PROC clear.screen = 


SER 
creen { esc: "|" '2). 3g) -~-~ clear screen sequence 
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Seseemmreesc; ‘'['> ‘H's: --- home cursor 


-- PROC pos.cursor (VALUE line, column 


KKEKRAKARRAKKKARAKKKRKKKKKEKRKKKAKRAKKAERKKAAKRKKRKAAKKKRKKKRKK 


DESCRIPTION: Positions the cursor in a specified line and* 

column. We have used the ANSI escape sequence 

ESC [Line;Column H. 

USAGE: pos.cursor (8,30) . x 

REMARK1: Valid values for line are O up to 24 * 
Valid values for column are 0 up to 80 x 

REMARK2: Values out of the above range will cause : 


unpredictable results. 
KAKKAKKKKERRERAAAERRAARRAAKERARARERAKRRAKAKAKKKRERKKRKKKRKKKRE 


a + 


PROC pos.cursor (VALUE line, column) = 
yee lee the cl. 7 | SYlb 2): 
O 


F 
(line < 10) AND (line >= 0) 


SEQ 
y eee 3 := 'Q! 
y (BYTE. 1] := line + #30 
(line >= 10) AND (line <= 24) 


SEQ 
y {BYTE a = eee re + #30 
Vet pYIn ol) = eel anes 10) +730 
TRUE 
SKIP 
IF 
Veep < 10) AND (column >= 0) 
S 
2 Byte 0 = 'Q! 
x [BYTE 1] := column + #30 
econ una >= 10) AND (column <= 80) 
SEQ 
x eae 4 = eee cng + #30 
x |BYTE 1 = (column\10) + #30 
TRUE 
SKIP 
Screen ! esc; '[' ; y ae 4 ; y eae 1] ieee 
Serevce 0 Peery Ls nk ee 


-- PROC new.line (VALUE number 


aE H RANK KARRNKAAAARARRREAED 
DESCRIPTION: It will skip as many lines as specified in 


USAGE: new. line(4) . | ~ 
REMARK: Negative numbers will not give any new lines “s 


geod new.line (VALUE number) = 


-- PROC s 


SEQ i = [0 FOR number | 
Screen ! cr;lf 
SKIP: ; 


¢ space (VALUE number 
KRAKKRKAAKARAAKKKKAKAKRAAKAKKKKAAKKAKRKAARAKKAAAKKKARKRKAKRRAKKR 


DESCRIPTION This procedure provides spaces for formatting* 
a Single line. as 
USAGE : spaces) . 4] 
REMARK: This routine does not Bpovece an automatic lf x 
after reaching the end of the line. AS 
KKARAKKAKARKKKRAKKRKEKERRAKKRKAKKERAAKKRKAKKAKAKAKKAKRRKAKKAKK 


hen (VALUE number) = 
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SES 1 = [0 FOR number] 
Green “!9sp 
SKIF- 


== SERS Cea (VALUE number 


RAKAARKKKKRKKAKKKKKKKRKRKKRRAKRRKRKRKRKKRRKRKAKRKRKRRKRKRRKRKKKRKKRKKKRKKERKAER 


DESCRIPTION This procedure provides tabs for formatting a* 
single line. Each tab is equivalent ta 8 spaces ree * 


terminal is using the default set up. * 
USAGE: tab(6) | * 
REMARK: This routine does not Pi Ov acs an automatic 1f * 
after reaching the end of the line * 


RRRAKKARKAKKARAKKKKKK AKAKAKKKKKKAKRKRAKKAKAKAKAKKKKKAKAKAKER 


ence tab (VALUE number) = 
5 


SEQ 1 = {0 FOR number] 
Screen ! tab 
SKIER: 


VALUE string[],start,string. length) 


KH RAKKKRAKRAK RRR IKARIA A RE RAR KARR RRARRRKRKRRE 


DESCRIPTION: This routine sends aysthing scaneucied s 
generic channel output. It also allows to specaty a start 
byte, as well as the length of the string to send. x 
USAGE: send.string (out.channel,"hello',3,3 * 
REMARK1: The above example will actually send the zi 

* 

* 


. 


characters 1,l.and o. 


REMARK2: It can be used with the channel Screen as well. 
KER RAKREKAKKARKRARKRERAKRKK RRA KRARRAR RE RARARRARRRKRKRKKRERKKEK 


PROC send.string (CHAN output, VALUE string{],start,string.length) = 
SEO 


SEQ index = [start FOR string.length] 
peor u ! string [BYTE index] 
Pe 


-~- PROC receive.string (CHAN input, VAR string{], 
VALUE start,string.length 


KAKAAAKKAAKKAKAKRAKAARARAKKRARKARAKKRAAAKKKRAAKRRARKAAARRARRARER 

DESCRIPTION: This routine receives a string through a 

generic channel input. It also allows to speci he 7 
es LO receive 


ACA a A 


PROC receive.string (CHAN input, VAR string[], 
VALUE start,string.length) = 


SE 
320 index = [start FOR Se eecie ae 


~~ PROC send(VALUE channel.id,dest.transp 


embuUG 2 Strings/Syl= index 
Shoe: 


9C_ send(VALUE channel. ic . transp ,message[] ,start byte, size) 
KRRKAKAKARAKRRARKKKAKKRAARKARK KRAKKARAKRKERAKARAARREKRKKKAKKKARKKER 
DESCRIPTION: It is an operating system routine, and it 
is used to communicate between processors. It builds the 
header of the message to be sent. It has as parameters 
the channel id of the channel which is going to carry on 
the communications, the id of the destination transputer 
for that message, the start byte and the size of the 
message to be transmitted. For every send must exist a 
receive for that same channel id in the destination 
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YS a a a a 9 


transputer. 
USAGE: send WD oe BOSSE aay | | 
REMARK: The user must be familiarized with the Operating 


System Structure before using this routine 


* 
* 
* 
k * 
KRARKKAAKKAKKKRKARKRKKKKKRKRKRKKRKKRKRKRKRKKRKKRKKRKAKARKRKKRKKRKEKRKRKRKRKKRRARAERE 


PROC send (VALUE channel.id,dest.transp,message[],start.byte,size)= 
VAR out,message.size,header [BYTE 5]: 


9 
F 
size <= 0 --- send from the start.byte all way to the end. 
J ecteomioelodels Valid Or messages up Lo 255 bytes. 
peeeevenezor size < 0 it behaves like 1t was a 0. 
I Nolte Ae := (message[BYTE 0] - start.byte) + 1 
TRU 
message.size := size 
header [BYTE 1] := Beer es oc( cee =o DlOgm=size (i? Of 256 bytes) 
Meader ote — Message. sizeé\Zo6 === + remainder 
header {BYTE 3] := channel.id --- any tenth from 40 up to 240 
header {BYTE 4] := dest.transp --- destination transputer 
out := route.table [dest.transp]_ | 
eee SL LCE. OUTEUL (chan[channel.id + out] ,header,3,1) --- ready flag 
I 
out = 4 
SE | | 
BYlE.SLICE.OUTPUT REE os eeeeeaeoce ae 
4 a aad link4,message,start.byte,message.size) 
out = 
SEQ | | | 
BYTE.SLICE.OUTPUT Re Opera eater 
. 2 ich elacehichcedaad link5,message,start.byte,message.size) 
out = 
SEQ 
BYTE .SLICE.OUTPUT PEE oute oa eo cat ceeeeeae td 
" Bee OURCE OUTPUT link6,message,start.byte,message.size) 
out = 
SE | | 
BYTE .SLICE.OUTPUT (link7,header,1,header.size) | 
Ya TPUT (link7 ,message,start.byte,message.size) 


Boe. SL ECE .aU 
BYTE.SLICE.OUTPUT (chan[channel.id + out],header,3,1): --- done flag 


-- PROC receive (VALUE channel.id,VAR messa el]. message. length[] ) 
RARAKKAKKKAKKAAKKAAKRKAKKKKKKKKRKKAKKA KKK RRAAKRKKRKRARRRARR RAR 
DESCRIPTION: It is an BeGuSelng system routine, and it 
Beesed LO Communicate between processors. It receives 
the incoming message, and provides as an output parameter 
the size of the message just received. The parameter 
channel 1d must have an exact match with the send 

pps ration which originated that message. 

USAGE: receive (70,message.in,size) 

REMARK1: The user must be familiarized with the Operating 
system Structure before using this routine. 

REMARK2: Notice that the message.length output parameter, 
must be a unity array of integers, while the message 


1tself must be declared as an array of bytes. 
RARKARKKKARKKKAKKKRKAR KARA AKKKAKKA KKK KAKKARKAAKRAKRAARKARKARKKKK 


4- 


* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 


BOC receive (VALUE channel.id,VAR message[],message.length[])= 


ORD SLICE INPUT ea 


channel.id],message.length,0,1 
Bales bLCE.INPUT (chan 


channel.id] ,message,1,message.length[0]): 


Gemeutllities . 

seerROC tick.to.time (VALUE start, stop board. type ) 

mm KEKKKKKKKKKKKKKEKKAKKKKKEKKERKREKKAAKKKKEKRKKRREREKKRRRRERRERKRERE 
b 


--- DESCRIPTION: It expects the board type which can be * 


oD 


---  board.type = 0 ----> OPS (VAX VMS) 
~— board. type 1 ----> BOOl (T414:12.5 MHz) 
--- board.type BOOZ 


--- board.type 31----> BO0O03 eae MHz - high Sar 
“<- board. type 


32----> BOO3 (T414:1 SMHz - low pri 
=o board.t 004 


e B 
--- and 2 signed integers vepres aay some tick values 
--- obtained by an aSsignmént of the type TIN eesec tem 
--- It then outputs the corrected elapsed Cime In hours ana, 
--- sec and msec, already taking into account the fact that 
--- the timer wraps around when it reaches MAXINT or MININT. 
~-- USAGE: tickk.to.time (timel,time2,31) 
--- REMARK: Although it takes care of the wrapping, it won't * 
222 ses track of the number of times you have completed one * 
--- full cycle of the timer. In order to solve this problem 
--- you should record roughly the start time. For example, in* 
--- the VAX/VMS, the full cycle of the timer is 7.2 min, so * 
--- if you get the elapsed time of 5 min 7 sec 320 msec and * 
--- you have Gok a rough total time of 12 minutes, then the , 


--- real total time is 12 min 19 sec 320 msec. 
wm KRKKKKAKKKKRAKKRKERKRERARRRRERRRE RRA RARKRRERREREKREKKKERKERERE 


How ae 
NO 
i 
‘ 
i 
t 
V 


A OO 


PROC tick.to.time (VALUE start, stop, board.type) = 
-- constant definitions 


DEF vax.sec =10000000 : --- hundreds of nsec/second 

DEF vax.mil1 = 10000 : --- hundreds of nsec/milisecond 
DEF bOOl.sec = 625000 : === + Of Lao) Usec, cecoma 

DEF bOOl.mili = 625 ; --- # of 1.6 usec/milisecond 
DEF bOO3h.sec = 1000000 : --= # of usec/second 

DEF bOO3h.m1ili = 100 --- + of usec/milisecond 

DEF S003] 7 see. =) boe25 “se + Of 64 Usec, second 

DEF b0031.mili = 16 --- # of 64 usec/milisecond 


DEF max.number.of.ticks = 2147483648 : --- maximum integer (2**31) 
VAR elapsed.tick : 

VAR factorl, factor2 

VAR msec, tot.sec, sec, min, hr : 


ee 


board.type = 0 --- VAX VMS 
23a) 
aclorl ;= Vax sec. 
factor2 := vax.mili 
poeueaevEe = 1 “=~ BOOL 
la 
factorl := p00l.sec. 
factor2 := b001.mili 
board.type = 2 s=— 7 BOOzs 
SKIP --- not implemented 
Boand. Ee = 31 --- BO03 in high priority 
3 
oe eae := bOO3h.sec 
factor2 := b003h.mili 
Posne eyes = 32 --- B003 in low priority 
E 
Paeeoes := bOO31.sec 
factor2. := b0031.mil1 
board.type = 4 =--s 004% 
SKIE -~-- not implemented 


e epee Cees s= stop - start 


aa peso < 0 
elapsed.tick := elapsed.tick + max.number.of.ticks 
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TRUE 


SKIP 
tot.sec := elapsed.tick/factorl 
AY := tot.sec/3600 
min >= (tot.sec\3600)/60 
sec s= Tot.sec\ Gu 
msec := (elapsed.tick\factorl)/factor2 


--SOUuBUC fine comscreeld 
write.number (hr 


ea tesstrange<' hr!) 
Write.number (min) 
merce. string ("' min ') 


write .number(sec) 
Velteasmeng |! sec |) 
write.number(msec) 
mpate.string (" mseql) 


== PROC dump (VALUE begin.address, count 
me KARKKAKKAKARKARKKAKKAKKKAKKKKKKARKAKKKAKAKAKKKAKKKAKAKAKAKKAARARK 


--- DESCRIPTION: This procedure dumps the memory starting at * 
Seemene Given "begin.address''. The value for the a 


==-- 'begin.address" can be either in hex or decimal. | 
Poeeune Count value determines how many words in memory will 
Se oe retrieved. 

m== USAGE: a) dump (#80003540,100) 

= b) dump (1024,48) 

So specu =5113,1024) 





--~- REMARK1: When specifying the count value remember that 
Seeecae cetrieval is done by words, not bytes!!! | 

Geek euAgkK2: Ff count 1s not a multiple or 4 it will use the 
Seeeclosest upper multiple. 

=== REMARK3: Negatives or zero values for count although 


2S5 accepted will give you no output. 
men AAAAKKAAKAKAAKARARKAKAKKKAKKAAKAKKAKKAKAAKKARKAKKRAKRRAAKKKR A 


A Oa 


PROC dump (VALUE begin.address, count) = 
VAR word.read: | 
VAR hex.value [9], hex.addr[9]: 

VAR address, align, times: 


SEQ. 
times := 0 
new.line(1) . 
address := begin.address 


-- aligning a given address 
oe := address\4 


align =<> 0 
gecress := address - align 


SKIP 


eer times <= count 

& 

write.strin "address '') 
dec.to.hex ta dress ,hex.addr) 
Wetee gs tt tnd eee 
ees te Ang Weoeee > 5!) 
SE e = [0 FOR 4] 


ETWORD (word.read,address) 
dec.to.hex (word.read,hex.value) 
write.string (hex.value) 
space(2) | 
times := times + 1 
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address := address + 16 
new.line(1 


-- PROC transfer.rate (VALUE start stop board. type nr of bytes 
mann KKKKKKAKAKKKAKKAKKKKAAKKRKAKAKRKAKRAKRKRRARKRKARKKRRRARKKAKKKAERERE 
--- DESCRIPTION: It is basically the same routine as %* 
--- tick.to.time, with the only difference that it returns a * 
--- rate value in Kbits/sec instead of a time value. x 
--- USAGE: transfer.rate (timel,time2,31,4096, rate) * 
--- REMARK: If further information is needeay pleacemm eam to% 


--- routine tick.to.time 
mmm RKKKKEAKKKKARKRKRKKKRAKAKAKKKEKKKEKKKKKKKAKKKKKKKKKKKAKKKKKKKKKK 


,VAR rate) 


PROC transfer.rate (VALUE start,stop,board.type,nr.of.bytes,VAR rate) = 
== CONS came ce fine one 


DEF vax.sec =10000000 : --- hundreds of nsec/second 

DEF bOOl1.sec = 625000 : --- # of 1.6 usec/second 

DEF bOO3h.sec = 1000000 : “-- + or usec/second 

DEE DOUSE sec =  sGZe: ~-~- # of 64 usec/second 

DEF max.number.of.ticks = 2147483648 : --- maximum integer (2**31) 


-- variable declarations 
VAR élapsed.tick : . 
VAR factor : --~ to-.convert ticks to seconds 
SEQ | 

elapsed.tick := stop - start 


elapsed.tick < 0 


elapsed.tick := elapsed.tick + max.number.of.ticks 
TRUE , 
Ski. 
-- selection of correct factor iaw the board 
a 
board.type = 0 —a VA vis 
factor := vax.sec 
board.type = 1 --- BOO] 
factor := b00l.sec 
board.type = 2 ===" 5002s 
SKIP --- not implemented 
board.type = 3l --- BQO3 in high priority 
factor := b003h.sec q 
board.type = 32 --- 3003 in low priority 
factor := b003l.sec 
board.type = 4 == BOOGs 
SREP --- not implemented 


oe rate calculation 
board.type = 32 mee . 
rate := ((nr.of.bytes*8)*factor)/(elapsedam ch Lio 
--- operation is done this way to keep precision ok! 


TRUE 
rate := connor oy Ee eae *(factor/1000))/elapsed. tick 
--- operation is done this way in order not to exceed maxint 


--- On the HumMeracor. ; 

--- Eee Py 8 due to 8 bits per byte 

--- divide by 1000 to have the tranfer.rate in kbits/sec 
SKIP: 


-- PROC capitalize (VAR ch) 
wm KKEKKKKKKEKKKKKKKKKKKEE KKKKKKKKKKKKKKKK KKK AKKKAKAKAKKKEKKE 
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=a 2 pie It capitalizes the first character in any 


--- Sere 


--- USAGE: capitalize string) 
ee... rare aia KRKKEKKRAKEKKRRAEREERERKKKKRKERERKRKERKREKKKKEKEKRKKKK 


PROC capitalize (VAR ch[]) = 


DEF delta =('a!' - 'A') 
“-- A --=> 65 
m“-- a-r-> 97 ASCII values 
ee, > LZ 
SE 
(ch, [BYTE 1] <= 'z!) AND (ch [BYTE 1] >= ‘a') 
h [BYTE i] := ch [BYTE 1] - délta 
TRUE 
SKIP 
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HF OF 


APPENDIX D 


THE OPERATING SYSTEM FOR THE ROOT TRANSPUTER 


(ROOT_OS.TDS) 


mam KKKKKKKKKKKRKRKKKKKRKRKRRKRRRRRKRKRKRKRKKRRKRRRRRRRRRRRRKRKRKRKRKRKRRRKRRRRRE 


--- Pitles ROOTsGs. tps * Version: 1.0 * 
c-- Author: MAURICIO DE MENEZES CORDEIRO * Mod: 0 * 
ae Date: 21/MAR/1987 KKKKKKAKKKKKKKKKKK 
--- Programming rel babs OCCAM 1 - 
--- Compiler: IMS D-600 -(VAX/VMS) 


x 
Brier Description: This program contains the source * 
code for a communications operating system for the * 
root processor in a network of transputers. It must i 

x 


be placed in parallel with the user process. 
KRAKKKKARKKKAKAKKARKKKARAKAKRKARARARKAKKK AAR KA KKERARARKRARKKRA 


| 
| 
4 
pa a is Sa SE Si Si a Si Sa Si Ss Si Ss Sa Sa SS 


=<= Mod #: | Date: — * 
a Responsible: | a 
--- Brief Description: * 
- = = x 
mann KAKKKARKKKARAKARKAKAAKAKAKKAKAKAKKKKAKKAKKKRARRA AA KKKKRRRRER 
SS Mod #2 Date: 
= Responsible: | . 
aa Brief Description: é 


mmm KAKKKKKRKKKKKRKRRKRKRRKRKKRKRKRRKRKRKRKRRRRKKRKRRRKRKRRRRKRRKRRRKRKRKKRRKRRRERRE 


-- Operating System global declarations 
DEF max.block.size = 4100: 

DEF nr.of.transputers = 17: 

DEF header.size = 4: 

DEF scrn = 40: === channe ieseuecn 
DEF max.io.channels = 25: --- 0 up to 240, in tenths 
DEF max.screen.channels = 5: 
VAR route.table[18]: 


VAR flag [BYTE 1]: --- for the library routines 


CHAN chan [10 * max.io.channels] : --- Actually it should be 


~--(10%*(max.io.channels-1))+8 


CHAN screen [max.screen.channels] : 


-- global_def.tds 
mn an  KAKKAKERKARARKARKREARKAKKAKKKKAKA RRR RR AKKKKKKAKKKAKKAR RRR RRR 
— At this point we should imbed the filed fold x 


--- global_def.tds, which is described in Appendix B * 
mann KAKRERAKA RA RKAAAKAKRKAREKAKKKRAKARKARARRKKKKRAERARKKKRKRARKKE 


as Pepe ter tl Pee Placements 
CHAN linkO AT linkOin : 
CHAN linkl AT linklin 


CHAN link2 AT link2in 

CHAN link3 AT link3in : 
CHAN link4 AT linkOout: 
CHAN link5 AT linklout: 
CHAN link6 AT link2out: 
CHAN link? AT link3out: 


==) LOO lp mates 

-- io_routines 

== PROG dec. to. hex (VALUE integer VAR string| ]) 

wana KRRKKKAKAKAKKKAKAKKKRAKAKKRRAKKKAERKAKKARK RERRERAKKRRAKKKKRK 
--- DESCRIPTION: It converts an integer number seuommuc z 
--- decimal representation into the equivalent hexadecimal * 
-“e- one. It accepts any valid anteger eG ereeumn omens x 
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--- hexadecimal number stored in a string of 10 bytes long 
--- where the leading zeros are preserved. 

--- It returns the following format: [size]#0000FFFF 

=== USAGE: dec.to.hex(37182,hex.string) . 

=-— REMARK: The ee) Sreeiemocradnd Ganhies Les length 
“--- which is always 9, therefore it could be deleted, but 


--- we decided to keep it. 
mm KK KKKKKKKKKRKAEKKKERKRRKAKKKARAKRKKKAKAREKRERERERKARERER ERE 


> SP i SP i a 


PROC dec.to.hex (VALUE integer, VAR string []) = 
wekecirst, order.of.diglt, digit : 
VAR number : 
DEF hex.char = "0123456789ABCDEF" 


Bee 

irst := TRUE 
string [BYTE ‘4 
seeing | BYTE 1 
number := integer 
Seder.or.dlgit = 9 . 
WHILE (number > 0) OR (first=TRUE) 


ou 


S, 
se - 


igit := number /\ #F 


Gagites= Nhex.char (BYTE digit + 1] - 
SoG ng (TE auemonder .OL.digit| := digit 
number := number >> 4 a 
Shasta meee  Orcer.Of.digit. - 1 


first := FALSE oe 
SEO — (2 FOR (order or.digit - 1) | 
String (BYTE aige— '0': 


--. PROC dec.to.ascii (VALUE integer, VAR string Ll) 
mm KRAKKKKAKKARKKKKKAKKAKKARKKKKARRKARKRAKKKAR ARR RAKE RERERARRER 


Meee USAGE: dec.to.ascii(-9873,ascii.string) . 
-=- REMARK: The BYTE[0] of the string carries its length 
--- which 1s always 11, therefore 1t could be eliminated, but 


--- we decided to keep it. | a 
mae KAKARKAARKAAAKKAKKAKKAKKAKKKAKKAKKKK KKKAKKKKAAKK KKK AKRRKRRER 


BeeeOBsCRIFLION: It converts an integer number from its — * 
Seemceciinat: representation into che 6quivalent ASCII one. It * 
=== accepts any valid integer number. It returns the ASCII aS 
=-- number stored in a string of 12 bytes pone where the s 
--- number is right justified and it has the following ss 
S00 format: = 3 42 -<-> re i 1 1] ii [J if i i pi Qrtg!) 7 | * 
sa00 1922937 “<-> J [i 1] | ie | SS a al he teste | * 

x 

* 

- 


Peoeecec.tc.ascil (VALUE integer, VAR string [!) = 
Pee number : 
VAR order.of.digit : 
DEF min.int = - 2147483648 


SEQ , 
number := integer 
Smder.or.digit := 11 
oo ae) [BYTE O] := 11 


Mumoeh = Min. ant 
-- taking care 
SEQ 


O 
th 
ct 
> 
m 


limit case 


Seriag sey le at Sac 
Sibing | BYTE male 
Serica BY Thee = '1! 
string |BYTE 4 = '4q! 
Shia | Sls o See 
Stang ae L7G = 'q! 
Sthing BYE 7 = ‘3s! 
Stringer BY lBae = '3! 
string [BYTE 2 | = '6! 
string |BYTE ie = '4! 
String WBYTE il = '8' 
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SE 
i 
number = 0 
SEQ 
string [BYTE 7 Tee 
string |BYTE Il}: =) 
order.ot.digit := 10 
number < 0 
SEO 
number := - number 
string [BYTE 1] := '-! 
TRUE === HUMDe mee) 


String (SM0h 0) eee 
-- pullding up the actual number 
WHILE number > 0 


sya, 
string [BYTE order.of.digit] := (number \ 10) + 
numberm <= (numbene, Fo) 


order.of digit :="order.cf-dicice—m 


SEQ i= {2 FOR (order. of. tonic e - 1)] 
string {BYTE i] := 


C2 ee Se SO Re OE OL gh Rl Ngee 68) WM Urs el eee Le, SENG ee 8 OL ween eae Oi Ole eee 


ees BOE ee Oe eee eee eee 


=== OBO Chor LION a. 2 pccepeen a hexadecimal representation or * 
--- aonumber and converts it into an integer number. It * 
=-= expects, the byce (Oi or see string to carry the size x 
--- information of that "hex number! * 
--- USAGE: hex.to.dec ("#00003785", number ,valid) * 
--- hex.to.dec ("#1452", number valid) “s 
--- hex.to.dec "#19574" number, valid) * 
--- ascil.to.dec (hex. string, number ,valid) * 
--- REMARK: Returns a boolean value FALSE in OK if the 

- 


--- string is not in the correct format. 
man KKKKK RRA RAIA EIR EAR RRA HRA BAA 


sale hex.to.dec (VALUE string [], VAR integer, OK) = 
5 
integer := 0 
IF . 
“= SNDGy Seren 
se eee 5 TBYTE oO} = 0 
:= FALSE 


= jhe xenumpe kr 
Sete Payee oO <> 0 


-- starts with '#' : 
String WBvie li =e! 
VAR Count 
SEO 
OK = TRUE 
Count 2 . 
WHILE (Count <= string [BYTE 0]) AND OK 
7595 e 8 pep Ree 
SEQ 
aEe hexChars = "0123456789ABCDEF" 
IF Index = FE FOR hexChars [BYTE 0] ] 
hexChars [BYTE ings = string [Byieeceune 
Digit := Index - 
ee 
:= FALSE 
integer: := feakelrs << 4) + Digit 
Coun = Counc 
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-- otherwise 
Sthingere. te lj <> "# 
OK := FALSE 


SKIP 


-- PROC ascil.to.dec (VALUE string[] VAR integer K) 
KKK ARRAKRRRRKRRAKRRRRRKREK LRKKKKKKKR A fe keeKKK EK 
a 


-<-- 2 epee ot It accepts an ascii decimal 


--- Boca neae Tow. of a number and converts it into an * 
--- eger number. It expects the byte[0] of the aaa * 
~ SS = carry the size information of that “ascil number * 
SeeOSAGH: ascii.to.dec (''-3785" number,valid * 
--- asGile tOnaec. (hao2"! ‘number, ‘valid * 
--- asGa ta romaee (ia al ‘number, ‘valid x 
--- ascii.to.dec (string, number valid) x 
--- REMARK: Returns a boolean value FALSE in OK eS the x 
--- string is not in the correct format. * 
mee KKKKK EEL RAR A CRKKARAA RRR RRR 


ees ascii.to.dec (VALUE string [], VAR integer, OK) = 
Betedar := 0 
ja 


== empty Strin 
ge ang {BYTE QO} = 0 
:= FALSE 


== a mumbe r 
Seeing isyik 0] <> C 
VAR Sign : 
VAR Start : 
VAR Length : 
SEO 
OK := TRUE 
IF 
-- negative 
seed Peyvte Lt} = r= 


Length := string [BYTE 0] - 


== positive 
Strang revle i| <> "=! 
SEQ 


Sign := 1 
Start := 1 ae: 
Eength s= string [BYTE 0] 
j-seonvert CO Integer 
i Index = [Start FOR Length] 
an Digit : 
“Bigit := string [BYTE Index] 


('Q' <s Digit) AND (Digit <= '9') 
meeder gleegemec 10) > (Digit - '0") 


OK := FALSE 
integer := integer * Sign 
S0G4 


-- PROC write string (VALUE string[]) 
mame KKKKKKKKKKKEKKKRERKKRRARKREREE HKRARERKKKAKKAKKERKKRERKK RAK 


--- DESCRIPTION: Writes a Seen string to the screen, ina * 
- byte by byte fashion. It requires that the string which * 
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--= 1s a byte array, provides the size of the vsStringeeamene 
==-"Dy re Of, otherwise we will get unpredictable estiieoee - 
“=~ are limited to strings up {£0 255 Chdraerer ose bigger 
ce pute dGbays Ob fOr Patera printing use "send® string 
USAGE : Wie see tiae ("He lor ae 


--- REMARK: It does no provide an automatic cr lL. 
mm KKKKKKKKKKKKKKKKAKKKKKKKKKEKREKKERAKKKAKRKERERRKEKKEKKKEKKE 


* 
* 
* 
kK 
x 
x 
TREE ae (VALUE string[]) = 

BYTE. sL IGE OUtc on sscreenie| flag Oe) 

ae 1 = (1 FPORMserongis aae 1] 

creen ! seat Een 
BYTE.SLICE.OUTPUT (screen(4]/7f£lag, 071) 


-- PROC write.string.fast (VALUE string[{]) 

manne KKKKRAAKARAAKAKRKARKARKARKKARARKAKKAAKRARARKAKKAKAKKAKKKKAKKKARKKE 
--- DESCRIPTION: This procedure works just in TDS and speeds * 
--- up things since the whole block 1s scheduledesyeerUnuae 
--- once, unlikely in the PROG write string whekeseadcumansee 
=== 25 Individual x scheduled. However the terminal driver 

=== Foutrne MUST ob 


-M 
7 
ay) 
S| 

10 
m 
OQ. 

48) 
ry 
ji 
O 
ry 
ct 
Oo 
ct 
Oy 
@m 
os 
3) 
@m 
O 
Kh 
ct 
“27 
t- 
Yn 
ry 
Oo 
(f 
ct 
H- 
2) 
@m 

OF OO OO OF OF 


eee eee (VALUE string[])= 
BYTE.SLICE.OUTPUT (screen[4],flag,0,1). 
BYTE .SLICE.OUTPUT (Screen, string, ! string ioclamow 
BYTE.SLICE.OUTPUT (screen[4],flag,0,1) : 


-- PROC write.number (VALUE integer) 

mmm KARAKARAKARKAARAAKAKAKARAAKKK RRA AKAAKKAKRRAKKAKAKAKAKKRK AKA 
--- DESCRIPTION: This PROC outputs a signed integer value to * 
--- the screen. It left justifies the number, so that if you * 
--- need it right justified, use the dec.to.ascii@and tEnen 


> 


--- the ea eine routines. a3 
--- It uses the following SHE We ; - 
--- -234193  ---> -234193 . 
aSe 1496 ---> 149 . 
--- USAGE: write.number (integer) i 
--- write.number(135 * 
mae KAARAKKAKKKKKAKAKKRARARKKKRKKRKAKKKAKKKAKRKKKAKKKARKKAKKAKKKAKRAAKKARAK 


PROC write.number(VALUE integer) = 


DEF min.int = - 2147483648 : 
DEF max.digits = ll 
VAR number : 


VAR order.of.digit : 
VAR digit (BYTE 2] 


SEQ 
number := integer 
order .of digi. == 1) 
a eso (screen(4],flag,0,1) 
si : 


number = 0 
SGReen ! ae. 
number = min.int 
Screen ! Pet st QV eMTstQrst7istAreiQre'3i.iGret gigi 
UE 


Screen ! '-! 


TRUE --- number > 0 
SKIP 
gee number > 0 
cen Mem@meer .Of.diqgle}| z= (number \ 10) + 'G' 

number := (number / 10) et 

mes OretHQnema— Order.Of.digit - 1 | nae 
BEE i= oP eHpoEnesgtt + 1) FOR (max.digits-order.of.digit) | 

creen ! digit [BYTE 1] 
BYTE.SLICE.OUTPUT (screen[4],flag,0,1) 


ee PROC read. string (VAR string[]) 

ma KKKAAKKAKAKKARARARARKAKKKAKRRARRRKKKKAKRRAKRAKRRAKRRKRARKERKK 
=-- DESCRIPTION: Reads any input sequence of characters typed* 
--- from the keyboard and stores them in a string, while 

--- echoing them to the screen. The PROC is exited when a 
eee cr’ is typed. — | | 

=== USAGE: read.string oe bedae a . 

See REMARK1: The byte|0] carries the size information of the 


Sigel ee wr 
7 REMARK? : Although it accepts strings of any length, the 
==- size contained in byte{0] will be reliable only for 
Seeseeings up tO 255 bytes. . 
--- REMARK3: To enter with strings bigger than 80 bytes use 
s=—"the lf key in the keyboard. | 
--- REMARK4: The set up of your cr key in vour keyboard will 
--- determine where the cursor will be at the end of the 


=-=- routine. 
me KK KRAKKKKAERKKRAKRKEREKAKAKKKKAKRKRKERAKAKKEKKEKARKAKAKKKARARREAS 


At AA TAHA AA A AA 


4 


PROC read.string (VAR string[]) = 
VAR n, char : 


char a ze 
n := 
BYTE-..SLICE.OUTPUT (screen[4],flag,0,1) 
WHELE char <> cr 
SEQ 
Keyboard ? char 
Screen ! char 


mos= not ol 

SErInctay rh) s= char 
Screen ! 
EXVIE.SLICE.OUTPUT (screen(4|,flag,0,1) 
Seeing(BYTE OO] :=n : 


-- PROC read.number (VAR number } 
mae KARKARARKAAKARKAARKAKKKAKKAKKAAKKKKKKRARKKAKK KKK RAKKKAKAKKRK A 


--- DESCRIPTION This procedure reads a number as entered from* 


--- the keyboard. It accepts the following entries format: 
== 4536122 <cr> 
a5 ts 7ec <ereo 
=a5 -573485 <cer> 


--- USAGE: read.number (into.integer) 

--= REMARK1: Only valid inputs will be echoed to the screen, 
@eemsO ic You enter with -34r5&6, the following will 

=s5 gener in the screen: -3456 meaning that the number 
-3456 was accepted. 

Semensrenk2: This procedure does not check to see if the 

SS enumoer 1s ped aee than MAXINT or smaller than MININT. If 
Gameeniat happens the result will be incorrect. 


--- REMARK3: An automatic cr,1lf is provided when exiting. 
wm KKKKKKKAKKKKKKARKKKRERKR ARK RERARRREKRRRREERREKERAERRRAKKRE 


OO OO OO A A A 


PROC read.number(VAR number) = 
VAR ch : 
VAR negative 
SEQ 
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-- P 


PROC 
SE 


PROG 


Chuge= elect 

number := 0 

ne cabs := FALSE 
YTE.SLICE.OUTPUT (screen[{4], flag,0,1) 

WHILE (ch <> '-') AND (ch <> basis AND ((ch < '0') OR (ch 
Keyboard ? ch 


negative := TRUE 
Screen ! ch 
Che 
Screen ! ch 
TRUE 
Ske 
WHILE ch <> er 


SEO 
WHILE (ch <> cr) AND ((ch <9 '90') OR (Che oye cee 
Keyboaka ¢ en . 
number := ( number * 10 ) + ( ch - '0' ) 
Screen ! ch 
Keyboard ? ch 
SKIP 
Screen ! 1£ 
ie 
negative 
number := - number 
TRUE 
Sicle 
BYTE .SLICE.OUTPUT (screen{4] ,flag,0,1) 


ROC clear.screen 


DESCRIPTION: It clears the screen and homes the cursor. 
USAGE: clear.screen 


> "9")) 


* 


KAKAKAKKAAKAKKERAERRARKAKAKARKAKAERERARAEERARRERAERERRRERERRRREER 


clear.screen = 


Q 

BYTE cbr Ca .OUrEUL Shai aes 

Senecn. 14ese;0 i" --- clear screen Sequence 
Screen ! esc; '{'; re --- home cursor 


BYTE.SLICE.OUTPUT (screen{4], flag,0,1) 


Ciel oe erat) 


DESCRIPTION: eens ons the cursor lin a eee line and 


column. We have used the ANSI escape sequence 

ESC [{Line;Column H. 

USAGE: pos.cursor (8,30) 

REMARK1: Valid values for line are QO up to 24 
Valid values for column are 0 up to 30 

REMARK2Z: Values out of the above range will cause 
BU Sed ae Oe de results. 


pos.cursor (VALUE line, column) = 


VAR x (BYTE 2], y [BYTE 2 


SE 


F 
wen < 10) AND (line >= 0) 
y (BYTE 0 
_ y [BYTE 1 + #30 
ee >= 10) AND Gene <= 24) 


y FRYE 9] 2 (lint 2 83 


— 


Ish) 


* 
* 
* 
x 
* 
* 
ra 


TRUE 


A SKIP 
el 
sconumn < 10) AND (column >= 0) 
S 
x TBE oO =, 
meey led = column + #30 
Koouaan >= 10) AND (column <= 80) 
5 
: BYTE 0 = eG + #30 
x [BYTE 1 = (column\10) + #30 
TRUE 
SKIP 


BYUB.oLDLCE .OULLEUT (screen[4],flag,0 
Screen ! esc; '[' ; y (BYTE 0 any 
oles away @, = oS 
BYTE.SLICE.OUTPUT (screen[4], lag,0 


? 


-- PROC new.line (VALUE number 

we KKKKKAKKKKKAKKAKAKKKRKK KAR KRKERKEKKEKKKKKRAKKRKEKRRKERKERRRARERER KKK 
--- DESCRIPTION.: It will skip as many lines as specified in * 
@-- its parameters list. in 
--- USAGE: new. line(4) > 


--- REMARK: Negative numbers will not give any new line es 
-=o- Be HRA AAR KERR AAR RRR ARARARAR RR ARAARERRRRRARRRRRRKK 


PROC new.line (VALUE number) = 


SEO 
BYTE.SLICE.OUTPUT (screen[4] ,flag,0,1) 
BER i = [O FOR number] 
ereen ! cr-ltf 
BYTE .SLICE.OUTPUT (screen[4],flag,0,1): 


-- PROC space (VALUE number 
mmm KKKKKKKEKKKRAKRRKKRREKK RARER RRR ERR KERR RRR RKEKKKRKRKEK EK 


--- Beene 2 TON This procedure provides spaces for formatting’ 
--- a single line. 


wo- USAGE? space(8) ‘ 
--- REMARK: This routine does not provide an automatic lf * 
j--- after reaching the end of the = 


ine. 
‘wm KAKKKKKRKKKKRE eee A RRA RN RRA RARKKKRRKKRRKKKRR RE 


BEC space (VALUE number) = 
S 


BYTE.SLICE.OUTPUT (screen[4],flag,0,1) 
SEQ i = [0 FOR number] 

screen ! ay 
Bete .SLICE.OUTPUT (screen[4],flag,0,1): 


-- PROC tab (VALUE numbe 
Oh AKAKARERAREKKARARRRKRRR RARER KR RRR RRR IR 
@eeeOescRIPTION This procedure provides tabs for formatting a* 
--- single line. Each tab is equivalent to 8 spaces if the 
--- terminal is using the default set up. i 
eee USAGE: tab(6) a 
“-- REMARK: This routine does not provide an automatic lf : 
x 


e-- after reaching the end of the line 
men KKKKAKAKKKKKAAKKKE KKK ARKKKRKERRREK RRR KERR RRR RRR KR 


a 


sage tab (VALUE number) = 


Q 
BYTE. , SLICE. OUTPUT (screen[4],flag,0,1) 
eet [O FOR number] 

creen ! tab 
BYTE.SLICE.OUTPUT (screen[4],flag,0,1): 


ler 


-- PROC send.string (CHAN output VALUE string[] Stairs string, length) 
mame KAKKKAKKAAKKKAKKAKAKRKKARKARKKKKKAKKRKKRAAK RARER ERARKRRRARARKAKRERE 
=-=- DESCRIPTION: This routine sends a pes through a a 
--- generic channel output. It alsovallovsmco specu a start * 
--- byte, as well as the length of the string to send. a 
--- USAGE: send.string (out.channel,"hello",3,3) * 
--- REMARK1: The above example will actually send the * 
--- characters 1,1 and o. ie 
x 


--- REMARK2: It can be used with the channel Screen as well. 
wm KKEKKKKKKKKEKKKKAKKKKREKRKRKRKARRKERERERERRRRRRERRKRRAKRRRERK 


PROC send.string (CHAN output, VALUE string[],start,string.length) = 
spa 


EQ index = [start FOR string. length] 
output ! string [BYTE index] 
Si hes 


-- PROC receive.string (CHAN input, VAR string[], 

VALUE start string. length) 

mam RKKKKAKKAKKARKEKARKRKRKKKAKAKARKAKKKAKKARKKAAKARKKAKAREKRAKRRKKKKKARK 

--- DESCRIPTION: This routine receives a String threughed 3 

--- generic channel input. It also allows to specity the ® * 

--- starting byte, as well as the number of bytes to receive * 

=== from the incoming strang. . . * 

=== USAGE: receive.string (cutschannel string aaron * 

~-- REMARK1: The above example will actually receive Z bytes : 
x 


--- from the incoming string, starting at byte ; 
wane KARKAKKAKAKARKAKKARKRKAAKRAKRKKARRARRKRRKKERERERKERKERARKARKKRAK 


PROC receive.string (CHAN input, VAR string[], 
ete Start seringsiengen). = 
SEQ 
SEQ index = (start FOR string.length] 
mt sie ? string (EYRE aces 


-- PROC send(VALUE channel.id dest. transp message | | start. byte size) 
we KAKAKAKAKKAKRARKARKKKKRKKKRARARARKKARARARKRKRRAAKARRRKRARKRRA 

=== DESCRIP ELON: fe. foam Breen system routine, and it 
--- is used to communicate between processors. It builds the 
--- header of the message to be sent. It has as parameters 
=--= the channel id of the channel which is) going towcarn acu 
--- the communications, the id of the destination transputer 
-=-- for that message, the start byte and the sizeporecce 

~-- message to be transmitted. For every send must exist a 
--- receive for that same channel id in the destination 

s=> Transpucer. 

--- USAGE: send (70,4,message,1,0 
--- REMARK: The user must be familiarized with the Operacime 


--- System Structure before using this routine. 
KREERKARKREKRRRARERRRER RRR RRR RE RERERRARRRRKRERARARRRERERAAKE 


A OO 


PROC send (VALUE channel.id,dest.transp,message[],start.byte,size)= 
VAR out,message.size,header [BYTE 5]: 7 : 


ca 


size <= 0 --- send from the start.byte all way to the end. 
--- this method is valid for messages up to 255 bytes. 
--- even for size < 0 it behaves like it was a OQ. 


BEE fe) JL := (message[BYTE 0] - start.byte) +1 
TRUE 
message.size := size 


header [BYTE 1 
header |BYTE 2 
header |BYTE 3 
header {BYTE 4 
out := route. 


message.sizé\256 -=- + remainder 
channel.id --- any tenth from 40 upeeome.e 
dest.transp --- destination transputer 
[dest.transp] 


serach 2k --- block.size ° of 256 bytes) 


oe 


ct 
pe) 
ox 
— 
(D> 
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Bema U ECE. OUTPUT (chan[channel.id + out],header,3,1) --- ready flag 


out = 4 
SEQ | | 
BYTE .SLICE.OUTPUT REA sce Stace byte ee . 
Be edt link4,message,start.byte,message.size) 
out = 
SEQ | | 
BYTE .SLICE.OUTPUT ES oop tore pene 
BYTE.SLICE.OUTPUT (link5,message,start.byte,message.size) 
out = 6 
SEQ ; 
BYTE .SLICE .OUTPUT Meise ecco ee ot ceder 3 817e) . 
EGC RECEP OUTEUE link6,message,start.byte,message.size) 
out = 
SEQ 


BYTE.SLICE.OUTPUT (link7,header,1,header.size) | 
BYTE.SLICE.OUTPUT (link7 ,message,start.bvyte,message.size) 
Be TEsoLICE.OUTPUT (chan{channel.id + out] ,header,3,1): --~= done flag 


-- PROC receive (VALUE channel.id,VAR message | | message .length[]) 
mmm KRKKKAKKKKKAKKKKKKAKKK AK KRKAKAKRARAKKKAKKKAKRRRRAKKKKARKARARKRKERE 
e-- DESCRIPTION: It is an Beer ating system routine, and it x 
--- is used to communicate between processors. It receives s 
--- the incoming message, and provides as an output parameter * 
--- che size or the message just received. The parameter = 
Seemcniaihe? 24 must have an exact match with the send 4 
*-- operation which originated that message. * 
SeeevoAGE: receive (70,méssage.in,size) = 
--- REMARK1: The user must be familiarized with the Operating * 
--- System Structure before using this routine. x 
SeeeneMaAkRKZ: Notice that the each eae kas output parameter, * 
--- must be a unity array of integers, w * 
Rn 
x 


==- itself must be declared as an array of bytes. 
ma RARKKKAKAAAKRAKKARKAKRAKRAAKKAKKKRAKKKAAKKERKKAKAKRKKRAKERAKKKKERKERK 


ile the message 


4 


PROC receive (VALUE channel.id,VAR message[],message.length[])= 


Sa) 
WORD .SLICE . INPUT Ee ee Orie | aaa mee beet 
BYTE.SLICE.INPUT (chan[channel.id] ,message,1,message.length[0]): 


Boeutilities 

mame moc tick.to.time (VALUE start, stop, board. type) 

mann KKAKKKARKKKKAKKKKAKKAKKKR KA KARKAKAAKAK KKK ARK KAAAEKARARKRERRA 

--- DESCRIPTION: It expects the board type which can be 

Game DOard. type, = 0 =-=--> OPS (VAX VMS 

---  board.type Ll ----> BOO] (T414:12.5 MHz) 

a board.type Boo Ja) O10)% 

=== board.type = 3l----> BO003 ee MHz - high can 

SOG board.type B20 5 1414: 1 Siz a elow (pel 

a board.type = 4 -=--> B004 

--- and 2 signed integers representing some tick values 

=== obtained by an assignment of the type TIME ? time.var | 

meee cnet OUlLDUTS) Che corrected elapsed time in hours, min, 

gaeecec and msec, already taking into account the fact that 

--- the timer wraps around when it reaches MAXINT or MININT. 

SeeeloAGE: tickk.to.time (timel,time2,31) 

=--- REMARK: Although it takes care of the wrapping, it won't * 

= es track of the number of times yeu have completed one * 

Gameeoe cycle of the timer. In order to solve this problem 

= yeu should record roughly the start time. For example, in* 
aie Veax/VMS, the full cycle of the timer is 7.2 min, so 

--- 1f you get the elapsed time of 5 min 7 sec 320 msec and * 

--- you have got a rough total time of 12 minutes, then the if 


--- real total time is 12 min 19 sec 320 msec. 
mm KRKEKKKKRKKKAKKRKAKKKRKKARKERKERKERKRREREREKRRKERERKEKKKEKKREKKEKRKKRERA 


e 
4 


AAA a A A A a et 
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PROC tick.to.time (VALUE start, stop, board.type) = 
-- constant definitions 
DEF vax.sec =10000000 : --- hundreds of nsec/second 


DEF vax.mili = 10000 : --- hundreds of nsec/milisecond 
DEF bOOl.sec = 625000 : --- # of 1.6 Uséecy cecond 

DEF bOOl.mili = 625 : --- # of 1.6 usec/milisecond 
DEF bOO3h.sec. = 1000000 : --- # of usec/second 

DEF bOO3h.mili = 1000 --- # of usec/milisecond 

DEF BOOS].sec = §15625.; --- # of 64 usec/second 

DEF b0O03l.mili = 16: --- # of 64 usec/milisecond 


DEF max.number.of.ticks = 2147483648 : --- maximum integer (2*%*31) 


VAR elapsed.tick : 
VAR factorl. acetone . 
VAR msec, tot.sec, sec, min, hr 


SEQ 
IF 
board.type = 0 == JE vie 
SEQ 
aCtOLr) :— Vaxesec. 
factor2 := vax.mili 
poe eC SRS = 1 So Stoll) | 
PacCkGuLe:= DOU Pesec 
PactorZe:= bOOlGmiis 
board.type = 2 site! JolO (072 
SKIP --- not implemented 
board.type = 31 --- BOO3 in high priority 
SEQ 
factorl := b003h.sec. 
factor2 := bOO3h.mil1 
board.type = 32 --- BO0O3 in low priority 
SE 
actorl := b0O3l.sec. 
factorZ == bOG@sl min: 
board.type = 4 === BOOd 
SKEE --- not implemented 
elapsed. tick ):= stop (s)5 cane 
Ir 
elapsed.tick < @ | . 
elapsed.tick := elapsed.tick + max.number.of.ticks 
TRUE 
SKIP 
tot.sec := elapsed.tick/factorl 
ne := tot.sec/3600 
min := (tot.sec\3600)/60 
Sec := pores Sour 
msec := (elapsed.tick\factorl)/factor2 


=-) OUEDWEM Eile s -Ou cc heen 
write.number (hr 


Write.string {7 ie 
write.number (min) 
Write string mins» 


write.number(sec) 
Write. Semingdsy. seca.) 
write .number (msec) 
write.string ('"' msec!) 


7= PROG dump | (VALUE begi add 


ae RR ee ee 2 picasa dee 


--- DESCRIPTION: This procedure dumps the memory starting at 
--- the given "begin.address". The value for the 

--- 'begin.address" can be either in hex or decimal. . 
--- The count value determines how many words in memory will 
--- be retrieved. 


--- USAGE: a) dump (#80003540,100) 
“a b) dump (1024, 48) 
. . c) dump (-5113,1024) 


--- REMARK1: When specifying the count value remember that 
--- the retrieval is done by words, not bytes!!! | 

--- REMARK2: If count is_not a multiple of 4 it will use the 
--- closest upper multiple. 

--- REMARK3: Negatives or zero values for count although 


--- accepted will give onl jee) Toilueei bY ar 
mm KAKKKKKKKKKKAKKKRKKRKKKRKAKKKAKRKKRKKAAKKKAAKAKKARAAKKRKKKRAKRRR 


> SS SA SA A a Ma MS Ba 


PROC dump (VALUE begin.address, count) = 
VAR word.read: 
VAR hex.value [9], hex.addr[9]: 
VAR address, align, times: 


SEQ. 
times := 0 
new. line (1) 
address := begin.address 
== alvgneng a given address 
align := address\4 
19) 
ees <> 0 
address := address - align 
TRUE 
SKIP 


WHILE times <= count 
Si 


write.strin Aece cues: ”) 
dec.to.hex eC dress ,hex.addr ) 
write.string eter 
wighuerstmincen |) ==> oll) 

SEQ i = (0 FOR 4] 


GETWORD (word.read,address) 
dec.to.hex (word.read,hex.value) 
write.string (hex.value) 


space(2Z) 

times := times + l 
SKIP 
address := address + 16 


new. Lline(l 
SKIP: 


-- PROC transfer.rate (VALUE start s top board.type nr of bytes, VAR rate) 
we KKKKKKKKKKKAAKAKAKKKKAKKRARKKKKKKKKARERRKKKKKKARRAERKKKKKARRKE 
Seo DESCRIPTION: It is basically the same routine as is 
Saemrick.tO.time, with the only difference that it returns a * 
--- rate value in Kbits/sec instead of a time value. * 
--- USAGE: transfer.rate (timel,time2,31,4096,rate) * 
SeereNaAnK: If further information is needed, please refer to* 


--- routine tick.to.time 
me KKKKKAKKKEKKKKKKKKKKEKAKKKKKKKKKKRKKKAKKKKKKKAKKAKKKKKKKAKKRKARKK 


PROC transfer.rate (VALUE start,stop,board.type,nr.of.bytes,VAR rate) = 
-- constant definitions 
DEF vax.sec =10000000 : --- hundreds of nsec/second 
DEF bOOl.sec = 625000 : --- # of 1.6 usec/second 
DEF bOO3h.sec = 1000000 : --- # of usec/second 
Der DOO3l.sec = £15625 : --- # of 64 usec/second 
DEF max.number.of.ticks = 2147483648 : --- maximum integer (2**31) 


115 


-- varlable declarations 
VAR elapsed.tick : 
VAR factor : --- to convert ticks to seconds 


EQ 
eee := stop - start 


elapsed.tick < 0 . 
Srp goetce := elapsed.tick + max.number.of.ticks 


SKIP 
= selection of correct factor iaw the board 
board.type = 0 --- VAX VMS 
factor := vax.sec 
board.type = 1 Sis js [0101 
factor := bOOl.sec 
bodnastype = = .2 == OO 2s 
SKIP --- not implemented 
board.type = 31 --- B003 in high priorit 
era ee b003h.sec pa ! 
board.type = 32 --- BO0O3 in low priority 
factor := bO0O3l.sec 
board.type = 4 ===" BO04 
Die --- not implemented 


-- rate calculation 


board. type 
rate := Ge of. Pyteeae *factor)/ (elapsed. tick*1000 ) 

ce operation is done this way to keep precision ok! 
hates.=-((nroce- ieee *(factor/1000))/elapsed. tick 
=e operation is done this way in order not to exceed maxint 
--- on the numerator. 
“<- retanac hr 8 due to 8 bits per byte 
--- divide by 1000 to have the tranfer.rate in kbits/sec 


SKIP? 


-- PROC capitalize (VAR ch[]) 

ma RKRAKKKAK AK AAKKAAKKKRKARAKARKAKKKARKARAKAKAAKAKRERRARARRKA AK 
=== DESCRIPTION: It: capltalizes tne aincs character in any * 
--- Seeoel as 


--- USAGE: cap italize (strin g) x 
mae raged arderageenral Pn: Pee ee ee ee ee SS SL eS See TS eee Te eee eT 


PROC capitalize (VAR ch[{]) = 


DEF delta =('a!' - 'A') 
--- A ---> 65 
--- a-r-> 97 ASCII values 
-2-= Z -=-> 122 
SE 
(ch, (BYTE 1] <= '2') AND (ch [BYTE 1] >= 'a') 
h (BYTE 1] := a [BYTE 1] - delta 
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-~ PROC operating. system 
PROC operating. ae = 
-- PROC input.handler 
PROC input. NeaHeT = 

-- variable and constants declarations 

VAR headerO [BYTE 5], 

headerl |BYTE 5], 

header2 jBYTE 5], 

header3 |BYTE 5], 


buffer. 
buffer. 
buffer. 


in0 
inl 
ing 


BYTE max.block. 
BYTE max.block. 
BYTE max.block. 


size 
size 
size 


~ ~~ ~~ ww 


buffer.in3 {BYTE max.block.size 
Block. sizel[t 


block.sizel|i 
Hi 
It 


, sanhielay- 
Seoul, 
Wola. 
. OU wore 


block -s1z2e7 
block.sizes| 


SE 
pena Cliaiaizing 
ae, i = [0 FOR 


Buffer. ind ere ) 
bulteer: Ble i 


the buffers 
max.block.size] 


buffer.in2 [BYTE i 
butter. (BYTE 1 
SKIP 


Wo a a 
Wht 


PAR 
WHILE TRUE 
-- listen to 
SEQ 
-- receiving the header 
BYTE .SLICE.INPUT (link0O,headerO,1,header.size) 


Linko 


= pecceee aS the ae Size 
block.size0(0] ((256 * headerO[BYTE 1])+headerO[BYTE 2]) 


an peers etnY Ene eeta ts . 
Byes ombeme Nr ULe( linc@®, butter.in0,1,block.size0[0]} 


IY 
-- the message is to be bypassed 
Boge [BYTE 4] <> this.transputer 


-- finding the best link to output that message 
.outdO := route.table [headerO [BYTE 4] ] 
=GUEDULIng EO Ene required a 

=== request ag thru chan 4, 5, oe 

Ene "SEICE. OUTP mcnantaueolt frecaeeors. 1 


OnEEO a 
BLeeaoLlcs.OULPUT nonta yneaderO,1,header.size) 
Bye ob teh. OULPUT 4 liank4d,buffter. ind, la 
block. $ize0[0]) 
outdO = 5 
SEQ 
Be. Sees. OULEUE pinks ,yhneaderO,1,header.size) 
Bite obleh OUGLUL (lanksS, buffer. ind, lle 
block. size0{0]) 
outO = 6 
SEQ | 
BYTE.SLICE.OUTPUT eee ,yneaderO ,1,header.size) 
BVth clLeneOUlPUL (.inke, puffer. ind, ip 


DHGG <x. size0(0]) 
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EQ 
BYTE.SLICE.OUTPUT need 
BYTE.SLICE.OUTPUT (link7?butre memes 


block.size0[0]) 
--- release flag 
BYTE.SLICE.OUTPUT(chan[out0] ,header0,3,1) 


ecw mossade is for this transpumen 
oe [BYTE 4] = this.transputer 


LF 
heaGerO [BYTE 3] <> secrn 
SEQ 


-- passing the size of the message 
ReRaer se || 
WORD.SLICE.OUTPUT (chan{headerO [BYTE 3j], 
block.size0 078 


-- Dvassing the message itself 
BYTE.SLICE.OUTPUT (chan[headerO [BYTEesias 
buffer.in0,1,block.size0[0] ) 


TRUE --- if channel.id = 40 = scrn 
SEQ 
==) mse aay, 
BYTE.SLICE.OUTPUT (screen[{0] ,neaderd 3,17) 


== OULPULEING to the gseneous . 
send.string (Screen buffer.ind 1 bloeli=e aman 


-- I'm done 
BYTE.SLICE.OUTPUT (screen[0],header0,3,1) 
WHILE TRUE 
-- listen to lLinkl 
S20 


-- receiving the header | 
BYTE.SLICE.INPUT (linkl ,headerl,1,header.size) 


== Gecoditig, tues block size 
block.sizei[0] := ((256 * headerl[BYTE 1])+headerl[BYTE 2]) 


-- buffering the een ge 
BYTE.SLICE.INPUT (link! ,buffer-inl,1,block=cezeuias 


re 
== the messages ts scouve bypaccea 
headerl [BYTE 4] <> this.transputer 
SE 


-- finding the best link to output that message 
outl := route.table [headerl [BYTE 4] ] 


-- outputing to the required link 

--- request flag thru chan 14> 157) lo ones, 
BYTE SLICE OUTPUT (chant 107 te aoe 
I 


BY IReotrcs OULEEE Tg 
BYTE .SLICE OUTPUT (linked (burften laa eee 
block.sizel[o}p 


outl = 5 
SEQ 
BYTE.SLICE.OUTPUT teneuerrsiti 
BYTE.SLICE.OUTPUT (link5,buffer.ini,1, 
block.sizel[0] ) 
outl = 6 
SEQ 


BYTE.SLICE.OUTPUT (link6,headerl ,1,header.size) 
BYTE .SLICE.OUTPUT ( linke butters ae 
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block.sizel[0Q]) 
outl = 7 
SEQ | | 
BYTE.SLICE OUTPUT Tee ia 
Eaboob ben. OUDPUL (link? ,buffer.inl,1, 


block.sizel[0Q]) 
--- release flag 


BYTE .SLICE.OUTPUT(chan[10+outl] ,header1l ,3,1) 
ec BEE GE is for this transputer 
nese [BYTE 4] = this.transputer 
S) 
Is) 
header) [BYTE 3] <> scern 
-- passing the size of the message 
eee ae 
WORD.SLICE.OUTPUT (chan{headerl [BYTE 3]], 
plock.sizel, 0/1) 


-- seeing pe message itself 


Benes oe UTPUT (c an{headerl {BYTE =) (1 
butter-ani, 1 ;block.sizel[0]) 
TRUE --- if channel.id = 40 = scrn 
SEQ 
-- I'm read 


sd 
Bares UL CH OU Ee UL. (screen[1],headerl,3,1) 
=- guest ern to the screen 
7s 


send.string (Screen,buffer.inl,1,block.sizel[0]) 
-- I'm done | 
BYTE.SLICE.OUTPUT (screen[1],headerl,3,1) 
WHILE TRUE . 
e-- listen to link2 
SEQ 


-- receiving the header 
BYTE.SLICE.INPUT (link2,header2,1,header.size) 


= geocceeg the block size 
block.size2{O] := ((256 * header2[BYTE 1])+header2[BYTE 2] ) 


saeoufferiag the Ji Reade 
Bore oLlCa iE UL (linkZ DuEfer.inz2,1,block.sizez{0]) 


12 
-- the ese ace is to be bypassed 
Sepa [BYTE 4] <> this.transputer 
: Q ees ; 
=e tinding the best link to on EP ue that message 
out2 := route.table [header2 [BYTE 4] ] 


-- outputing to the required link 
--- request flag thru chan 24, 25, 26 or 27 
BYTE . SLICE. OUTPUT(chan[20tout2] ,header2, 3,1) 


Brle omen OUTRUL (Tink4 buffer.inz,1, 


EVDE.SLICE.OUTPUT epee reas ee t2e) 
block.size2[0]) 


SE 
BYTE .SLICE OUTPUT Memeeeecce cing ener size) 
Bebo oECheOUBFOUP (links ,butfer.in2,1, 
block.size2{[0Q]) 
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BYTE.SLICE.OUTPUT Ae ,yheader2,1,header.size) 
BYTE.SLICE.OUTPUT (dinke pute in2 | Ih 
pbleekw size2(0]) 
out2 = 7 
Se 


BYTE.SLICE.OUTPUT ee yheader2,1,header.size) 
BYTE .SLICE.OUTPUDM Vink? ,euseer- in2, cS 
block. size2[0]) 
--- release 


BYTE.SLICE. OUTPUT (chan[ 20reUeeNl: header2,3,1) 


-- the message is for this transputer 
peso [BYTE 4] = this.transputer 
S 


F 
ne eoee [BYTE 3) Sco asern 


-- passing the size of ST me ay tee 
block. ‘igi 31] 
WORD. SLICE CULE UE (chanfheader2 (3 [BYrEsS 
block.size2,0, 


-- passing the message itself 
BYlE  ShLCh-OUTr Ulex c anne aden [BYTE se 
| buffer-inz , 1) b¥cew $ize2[0]) 


TRUE --- if channel.id = 40 = scrn 
SEQ 
-- I'm ata 
BYTE.SLICE.OUTPUT (screen[2],header2,3,1) 


as ieee utting to the screen 
send. ae ring (screen, buffer .in2,1,block.size2(0]) 


-- I'm 


don 
Brie. SLICE. OUTPUT (screen[2],header2,3,1) 


WHILE TRUE ; 
a IVSEGN GO limnics 
EQ 
ae Becca the header 
BYTE.SLICE.INPUT (link3,header3,1,header.size) 


-- seadenetel the block $1z 
block.size3[0] (C256 7% “ neader3 (BYTE 1])+theader3[BYTE 2]) 


= eae ae ise the Wenn eke 
BYTE.SLICZE.INPUT (link3 ,buffer-in3, 1] bicek ssizes 0 


IF 
-- the nes $2 0E 1s to be bypasses 
header3 [BYTE 4] <> this.transputer 
So 


-- finding the best link to ae nae message 
out3 := route.table [header3 [BYT 


-- outputing to the required link 
--- request flag thru chan 34732275 jonomes 
oe -oLLerr OUTPUT (chan[30+out3], header3,3,1) 


out3 = 4 


SEQ 
BYTE.SLICE.OUTPUT eases ,yheader3,1,header.size) 
BYTE.SLICE.OUTPUT (link4,buffer.in3,1 
block. 3i5e4T]) 
QUtse=05 


So 
SYTE .SLICE OUTPUT re ,neadenrs as header.size) 
BYTE.SLICE.OUTPUT (dink>sebweser: in3, ie 
Jajilrevayhe size3[0]) 
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BYTE.SLICE.OUTPUT Neer ,»yheader3,1,header.size) 
BYTE.SLICE.OUTPUT (link6,buffer. in3, Re 
block. size3{0]) 


BYTE.SLICE.OUTPUT rans pyheader3,1,header.size) 
BYTE.SLICE.OUTPUT (link? buffer. in3 


block. size3[(0]) 
--- release eee 
BYTE.SLICE.OUTPUT(chan[30+out3],header3,3,1) 


-- the message is for this transputer 
header3 [BYTE 4] = this.transputer 
SE 


“headers fEYTE. sillo<>tsern 


-- passing the size of the message 
Block. ie ee 
WORD.SLICE.OUTPUT (chanf{header3 [BYTE 3 
block.size3,0,1) 


== passing the message itself 
BYTE.SLICE.OUTPUT (chan(header3 (BYTE 3]], 
Surtersins,., bilo. $ize3[0]) 


TRUE --- if channel.id = 40 = scrn 
SEQ 
~ = I'm 
Bites SLICE. S OUTPUT (screen[3],header3,3,1) 


as Suet? Eomtne senesi 
send.string (Screen,buffer.in3,1,block.size3(0] ) 


-- I'm don 
BYTE. SLICE. “OUTPUT (screen[3], Headers By 1) 


-- PROC output.handler 

PROC output.handler = 
-- local variable declarations 
VAR flag4 [BYTE 
VAR flagS {| BYTE 
VAR flag6é |BYTE 
VAR flag7 [BYTE 


PAR 
WHILE TRUE | 
ALT i = fe FOR max.io.channels|] 
chan [(10*i) +4] ? flag4 ite QO] --- for link4 
BYTE.SLICE.INPUT (chan [(10*i) +4],flag4,0,1) 


CONDON 


Poet TRUE 
7 Oy as i FOR max.1o.channels | oe 
Cndinmeeenecy) to) 2 tlags (BYTE @Oie===sror links 
SYTE.SLICE.INPUT (chan [(10*4) +5],flag5,0,1) 
WHILE TRUE 
ALT k = iS FOR max.io.channels| 
Chan i4lOck) +6) ? ftlag6é Teck 0] --- for linké 
Pane oumer. INPUWCchan |( 107k) +6|],flag6,0,1) 
WHILE TRUE | 
ALT 1 = Fe FOR pees nannies S| 
Charmed) +7 lee flag? YTE 0] --- for link?7 
BYTE .SLICE.INPUT (chan 710#1) +7 |vttag? 70,1.) 


-- PROC screen.handler 
PROC screen.handler = 
VAR flag [BYTE 2]: 
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WHILE TRUE 


ALT i = 


-- SC PROC terminal.driver(CHAN Ke 
mm KKKKKKKKKKKKKKKKKEAKKER 


--- This routine is 


screen[i] ? Re 1) 
BYTE .sbLlece..Vhu 


ARKAKKK 


QO FOR max.screen.channels] 


T (screen{i], flagwaen)- 


yboard Screen, VALUE 
KKAKEKAKKKKKARKKKKKAAKKK 


rovided by the manufacturer, and it 


port baud. rate) 


--- varies with the Bae we are using. This particular 


--- one is for the BOO1l board. 
mm RKEKKKKKRKKAKKKKKKKAKAKAAKKERKKAKREKKKRKKRAKEKAKAKEKRAKKRARKRKRAKKE 


* 
* 
* 


-- PROC terminal.driver(CHAN Keyboard,Screen,VALUE port,baud. rate) 

PROC terminal.driver (CHAN Keyboard, Screen, VALUE port, baud.rate)= 
-- T414 Board Definitions 
-- declare constants 


Uae 
DEF 
DEF 


ppw ; 
DLES.pPer word 
perif.base 


Nou al 


see 
480040000 


-- duart register addresses 


-- base address of peripherals 


MR 


LEGR 
ACR 


ISR 
IMR 
OPGR 


CTU 
Gre 


SR 
CSR 


CR 


uartA 
uartA 


uartA 
uartA 


uartB 
uartsB 


uarta 
uartaA 


Wares 
uartsB 


uarts 
Udties 


No Fes eenenon 
interrupt on rx.ready 
character error mode 

disable parity 


8 bits per char 


-- See table 1 'Register addressing' on page 6 of 
=< the SCN2681 data sheet. 
-- These are all word offsets from address zero 
DEF Udiek “= perrn baceun Ome 
DEF uartB = perif.base + (8 * bpw) 
DEF mode.reg = 0 * bpw -- 
DEF status.reg = 1 * bpw oo) bead 
DEF clock.select.reg = 1 * bpw -- write 
DEF command.reg = 2 * bpw -- 
DERCracued = 3 * bpw -- read 
DEF tx.reg = 3 * bpw -- write 
DEF input.port.change.reg = 4 * bpw -- read 
DEF aux.control.reg = 4 * bpw -- write 
DEF interrupt.status.reg = 5 * bpw : -- read 
DEF interrupt.mask.reg = 5 * ppw : -- write 
DEF. AnDUE. Sore P = 5 * bpw -- read 
DEF OULTDUE.DOrt.conmeseg 9§ = 9 5°*~ Ep -- write 
DEF timer.upper.reg = 6 * bpw : == 
DEF timer.lower.reg = 7 * bpw : =o 
DEF start.counter | = 6 * bpw -- read 
DEF set.output.port.bits = 6 * bpw : -- write 
DEE Stop. councer = 7 * bpw -- read 
DEF reset.output.port.bits = 7 * bpw -- write 
-- declare register values 
=< "MRD modewmnedis cease. 
DEF rx.rts.control = #00 == mat 
DEP rx. int aseleer = #00 -- {6 
DEF error.mode = #00 == NS 
DEF parity.mode = #10 -- [4:3] 
DEF pal Seaeae = #00 -- {2 even parity 
DEF bits.per.char = #03 a jib 0] 
DEF MR1.control = rxirts-controie 

rx.int.select \/ 
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onl 
anak 


onl 
oni 


only 
only 


onl 
only 


onl 
oni 


onl 
one 


error.mode A 

parity.mode vy 

pee ey cys wy 
1ts.per.char 


-- MR2 mode register 2 


DEF channel.mode 
DEF tx.trs.contren 
DEF cts.enable.tx 
DEF step.bit.length 


: :6] normal channel mode 
DEF MR2.control = channel.mode \ 
\ 


7 

5 Bes CoMeso Menor ised 
4 Gis control not used 
220 (eel sOO0mstop DLEs 
/ 
/ 
/ 


| 
He 
Oo 
Oo 
§ 
§ 


Picea se Cone Ow 
ets.enable.tx 
StOD soles Lengen |: 


-- CR. command register 


DEF bit.seven #00 : -- [7] not used must be zero 


-- (6:4] misc comds never combined 


DEF no.command = #00 : . | 
Pee reset.mr.ptr = #10 : -- make mode register point at MR1 
DEF reset.rx = #20 : . 

DEF reset.tx = #30 ; 
DEF reset.error = #40 

DEF reset.break = #50 

DEF start.break = #60 

DEF stop.break = #70 

DEF enable.rx = #01 : -- [3 

DEF disable.rx = #02 : -- {2 

DEF enable.tx = #04 ; -- [1 

DEF disable.tx = #08 : -- {0 

-- SR. status register 

DEF received.break = #80 -- [7 

DEF framing.error = #40 == 16 

DEF parity.error = #20 \- {5 

DEF overrun.error = #10 -- {4 

DEF tx.empty = #08 => 18 

DEF pce! = #04 -- {2 

DEF £ifo.fuil = #02 -- {1 

DEF rx.ready = #01 -- 10] 


-- OPCR output port configuration register 
-- Mask this beast out before programming the timer 
DEF OPCR.control = #00 : -- [7:0] mask out output port 


-- ACR aux control register 


DEF brg.set.select = #00 : -- [7] select set 1 baud rates 
— for CSRA 
DEF counter.timer.mode = #00 : -- 8:5] external counter 
Be delta.ip3.0.aint — 00m -—suerOl= NO bits) in IPCR affect 
-- in IMR [7] 
DEF ACR.control = brg.set.select Wi 
counter.timer.mode \/ 


delta.ip3.0.int 


-- IMR interrupt mask register 


WP 


DEF IMR.control = #00: -- [7:0] no interrupts 


-- PAL bit registers 
-- RS232 RX data and switches 


-- T414 i/o 


noes 


-- PROC reset.uart (VALUE uart,baud.rate) 
PROC reset.uart (VALUE uart, baud.rate)= 


ee now, the.future 
Se 
PUTBYTE (reset.mr.ptr\/disable.rx /disable.tx,uart+command.reg) 
PUTBYTE (MRl.control, uart + mode.reg 
PUTBYTE (MRZ.control, uart + mode.reg 
PUTBYTE (ACR.control, uartA + alizucontnou eco) 
PUTBYTE (baud.rate, uart + clock.select.reg) 
PUTBYTE (no.command\/enable.rx /enable.tx,uart+command.reg) 
-- wait 1 
TIME 2 the future 
TIME ? now 


the.future := the.future + #40000 
WHILE the.future AFTER now 
TIME ? now 


SKIP: 


-- PROC read (CHAN out, VALUE uart) 


PROC read 
-- read 


CHAN out, VALUE uart) = 
rom keyboard with deschedule between polls 


VAR status, ch : 
SEO 
HILE TRUE 


SEQ 


==redad Staeus | 
GETBYTE (status, uart + status.reg) 


-- wait for received character 
WHILE (status /\ rx.ready) = 0 


PAR 
SKIP y 
-< ie Status again 
GETBYTE (status, uart + status.reg) 


-- read the character 
GETBYTE (ch, uart + rx.reg) 


-- output the character 


Ou: 


oKIP 


alle: 


-- PROC write (CHAN in, VALUE uart) 
PROC write (CHAN in, VALUE uart) = 
a= Write to uare 
VAR uart.falled : 


SEQ 


uart.failed := FALSE 
WHILE TRUE 


VAR 
SEQ 


cn 


at fen 
(ch < 0) OR (uart. failed) 
SKIP 
TRUE 


-- wrch (VALUE ch, wart) withetmmecue 
DEF timeout = 3200000 : 
nee status, count 


Q 
status := 0 
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count := 0 
BHILE ((status /\ tx.ready) = 0) AND (count < timeout) 


ETBYTE (status, uart + status.reg) 
count := count + l 


count = timeout 
uart.failed := FALSE Soo LKUE 


TRUE 
PUTBYTE (ch, uart + tx.req) 


SREP 
-- main orogram 
VAR uart : 
SEQ 
IF 
port = 0 
uart := uartA 
TRUE 
uart := uartB 
mes geguart (uart, baud.rate \/ (baud.rate << 4)) 
read Gate Bene 
write (Screen, Ware 
Skier : 
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08" body of the operating system 


-- receiving the sene ee table 
2= t 


route.table[0 --- output link to transp 
route.table|1 := tl === OUtCDUE Panky co. coaner 
route.table|2 := t2 --- output link to transp 
route.table|{3 := t3 --= QUtpUut linkerosrsance 
route.table[4 >= t4 --- output link to transp 
route.table[5 := 5 --- output link to transp 
route.table|6 := t6 —== OUCDUE Minn tOmenancm 
route.table!7 := t7 === OUtDUL fink toy teanae 
route.table| 3 := t8 “-- output link to transp 
POWcem eas le |,S := t9 -=-- output link Comtuance 
route.table|10 := t10 --- output link to transp 
route.tablej1l1l := tll --- output link to -transp 
route.table{12 >= t12 --- output link to transp 
route.table{13 := t13 “-- output link to transp 
route.table![14 := t14 --- output link to transp 
route.tablej 15 = tO --~ output. link to transp 
route. table[ 16 := t16 --- output link to transp 
route.table{17!} := t17 --- output link to transp 
PAR 
output .handler 
input.handler 


terminal.driver (Keyboard, Screen,port ,baud) 
screen.handler : 
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APPENDIX E 
THE OPERATING SYSTEM FOR REMOTE TRANSPUTERS 


(REMOTE_OS.TDS) 
me KKAKAAKAKAKAAAKKRKAKAKKRKKRKK KKK RKKAK KAKA KKAKKKK AA KAK KAKA KAKKK KR 
=== * Title: REMOTE_OS.TDS a Vers2on: 1.0.°% 
a Author: MAURICIO DE MENEZES CORDEIRO * Mod: 0 os 
= Date: 13/MAI/1987 KARKKKAKKKKKAKKKA 
aa Programming Te ee OCCAM 1 = 
Compiler: IMS D-600 (VAX/VMS) * 


Brief Description: This program contains the source * 
code for a communications operating system for remote* 
processors in a network of transpufers. It must be * 


placed in parallel with the user process. 
mm KK KKKKKKREKKRKEKEKRKEKKKKRKEKK RR REKRKRKRKKEKRKERERKERKRKERKKRRARE 


| 
| 
| 
i a a i a 


Se= * Mod #: | Date: : 
@--- * Responsible: 
-<-- e Brief Description: 
em KXKKKKKARKAKKKAKKKKKKAKAKKKKAKAKKAKKKAKKKAKKKKKKKAKKAKKAKKKKRKAK 
Beam x Mod #: | Date: i 
mae | 6 Responsible: 
-<-- ‘i Brief Description: i 


wee KKKKKKKKAKKKKKKKKRKAKKAKRKKKRKRKKRKRKRKKRKRKRKAKRKKRKKRKRKRRKRKRKRKRRRRRRERRRREREA 


-- Operating System global declarations 

DEF max.block.size = 4100: 

DEF nr.of.transputers = 17: 

DEF header.size = 4: 

DEF scrn = 40: S22) Channel screen 

DEF max.io.channels = 25: --- 0 up to 240, in tenths 

DEF max.screen.channels = 5: . 

Peneroute.table([13] : es 

VAR flag [BYTE 1]: | Oe toa eGOUE nes 

CHAN chan [10 * max.io.channels] : SES Sis 28 ge lel Jer 
---(10*(max.io.channels-1))+8 

CHAN screen [max.screen.channels]: 


-- global_def.tds 
mm a KAKKKERRRKKAKAKKRKKAKAKKKKK RRR AAKKKKRRERAKAAKKK RARER AKA RRR 
135 At this point we should imbed the filed fold . 


=== lobal_def.tds, which is described in Appendix B * 
mn KHARRKAKARKARKKKAAKKKKKKKKRAKKKRAAKKAKRRAKKKARRARKARKKRKKAKKKRK 


-- Peer ating Semen cnannes Placements 
CHAN linkO AT linkOin 

CHAN linki AT linklin 

CHAN link2 AT link2in 

CHAN link3 AT link3in : 

CHAN link4 AT linkOout:. 

CHAN link5 AT linklout: 

CHAN link6 AT link2out: 

CHAN link7 AT link3out: 


saeremote_lib.tds 

Se i0_routines 

SeeEROC dec.to.hex (VALUE an eegeh VAR string|]) 

mn KAKAKAKAKAAKAKARAKKKAKKKK KR RARKAKKAAKKKK KAKKKKKKKKKKRK 
--- DESCRIPTION: It converts an integer number from its a 
--- decimal representation into the equivalent hexadecimal * 
--- one. It accepts any valid integer. It returns the “ 


t2/ 


hexadecimal number stored in a eteang of 10 bytes long 
where the leading Zeros drewprecem oa 

It returns the following format: [size]#0000FFFF 
USAGE: dec. to.hex(37182,hex.string) 

REMARK: The see of the string carries its length 
which 1s always 9, therefore 10 could bemcetlec— i aou. 
e 


we decided to keep it. 
RAKRAKARAARKAKAKKRRARKRKRARKARKARARKARAKARAKAKARARARRAARKAARARK 


Se a a a a ao 


PROC dec.to.hex (VALUE integer, VAR string []) = 
VAR. first, order.of digit. diqite 
VAR number : 
DEF hex.char = "0123456789ABCDEF" 


-- PROC dec.to.ascii (VALUE integer 


seer te i = 9 
Stying || Babee |) := si 
number := integer 


Order.of digie = 72 | 
WHILE (number > 0) OR (first=TRUE) 


number /\ #F a 

digits:= hex-chary | BYiGedveni 
string [BYTE order of ,digqit) ~-— 
number := number >> 4 aa 
Order.of.digit := order. of.digutc: oan 
first +> Pabse — 

SEQ 1 = | 2. FOR <order vor. diqure— 1) 

string, (BYTE iijis:= "0": 


wr 
Q 

-P- 
ct 
Ta 


1]. 
able pkic 


VAR string {]) : 
KARKAAAKRRAKAAARKKARKKERAKKA RAR ARK RAKKKARAAKRRERKKRRARRKKARKRRR 
DESCRIPTION: It converts an integer number from its 
decimal representation into the equivalent ASCII one. ft 
accepts any valid integer number. It Freturns, ChesNsem 
number stored ina Pere) oe 12 ppees onde where the 
i as, the, £61 


number is right justified and it s the lowing 
format: = 3245 “<--> [re | 1 J I | | 3! 1S! 4! 12! 
° 1922937 -<-=—> I 1d J 14 ae ee” es) ce lh 9 | 


AO Oe OO 


USAGE: dec.to.ascii(-9873,ascii.string) . 
REMARK: The BYTE|O\*of the string canetesere. eee 
which 1s always ll, thererore it coula=bevelimingceay but* 


we decided to keep it. 
KRREKRKERREKKRRRRRK KARR RARKRRRRK KARA KAA RAKRARAARARAKKARKAREK 


PROC dec.to.ascii (VALUE integer, VAR string []) = 


VAR number : 

VAR Orcer of. digivim: 

DEF min.int = - 2147483648 

SEQ | 
number := integer 
order.of.digit := 11 
eteeng [BYTE 0] := 11 


number = min.int 


-- taking care limit case 


O 
Fh 
ct 
ox 
(D 


String (Byte! mie: cee 
Sta liGg |S anec = '2Z! 
Sthing | BYythss =e 
string |BYTE 4 = '4! 
SERINg Suites = '7' 
Sthing | Bele. > = '4' 
String wei Te 7] = '8! 
String BYE 7 = 13s 
stringi/PBYTE 9] = '6! 
string [BYTE “ee = '4!' 
stringiPBYTE Ta =) 8" 
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eae 
F 
ere = 0 
string [BYTE a = 
Seam (scree tt s— 'O' 
St .digit := 10 
number < 
SEQ 
number := - number 
string {BYTE 1] := '=-' 
TRUE --- number > 0 


SER EYlE ties | 
“- building up the actual number 
WHILE number > 0 


SEQ : 
Sumimege St le order.or.digit] := (number \ 10) + '0' 
number := (number / 10) 


Sorderrvot.digit :— order.of.digit - 1 


SEQ 1 = {2 FOR eae of. poet - 1)] 
string [BYTE i] := 


=~ PROC hex.to.dec (VALUE string | . VAR integer, OK) 
wee KKKKKKKAKAKAAKKARAKAKKAKKAKKKKKERKAKKARKRKKK AKA RKKAKRARAKKAAKKRARAKAAK 
--- DESCRIPTION: It accepts a hexadecimal representation of * 
--- a number and converts it into an integer number. It * 
Zmmexoeces che bvee(0| of the string to carry the size a 
--- information of that "hex number’. * 
w-- USAGE: hex.to.dec #09003765" number, valid) x 
“<< hex.to.dec ("#1452" number,va Lid) * 
--- Nexeee dec "#19574" sumber, valid) x 
--- ascii.to.dec (hex. string, number , valid) * 
=== REMARK: Returns a boolean value FALSE in OK if the : 
- 


--- string is Moe In tie correct form 


ace 
anew KKKKK ee eee AAA AL ARR ARRRAKKRRR RRR RRR 


eer oes (VALUE string [], VAR integer, OK) = 
SE 
integer := 0 


-- empty strin 
string (BYTE 0 = 


See nex number 
eering PS 7TE Ole <> 0 
F - 


Pemocat is Wate Le! 
string [BYTE 1] = '#' 
VAR Count : 


OK := TRUE 

Count := 2 

WHILE (Count <= string [BYTE 0]) AND OK 
VAR Digit : 


zee hexChars = "0123456789ABCDEF" 
IF Index = tA FOR hexChars (BYTE 0] |] 
hexChars [BYTE ences = string [BYTE BON) 
= Index - 
:= FALSE 


aubegess := (integer << 4) + Digit 
Coun Counc + 


Zo 


-- otherwise 
string [BYTE 1] <> '#! 
OK := FALSE 
SKIP 


-- PROC ascii.to.dec (VALUE string| | VAR integer OK) 

me RAKEKKKKKRKAKKKKRAKAKKRERKARKAKRERAAKAKRAKRKRERAAKRKAAKRKKRKKK 

“<- DESCRIPTION: It accépts an ascii deci 

=== ped bata aac of a number and converts 1t into an 
integer number. It expects the byte[0] of the string 

--- to carry the size information of that "ascl1 number". 


phe ascii.to.dec ("+1l45z2" number valid 
--- ascil.to.dec (UI9574" ‘number vee 
a ascii.to.dec (string,number,valid) 


-~= String 1S Rou in Ene Correcessouna 
mame AAKKAAAKAAREKRAAKARAKARRAARRKAARAKAKAKAAKARKKKKAKAKRAKKKAKKKKA 


A Ae A he 


PROC ascii.to.dec (VALUE string [], VAR integer, OK) = 


SEQ 
Lnteger = 0 
= Seno uy eochane 
string [BYTE OJ] = 0 
OK := rALSE 
-- number 
String |Byi5,.0 | "<> 8 
VAR Sign 
NAR © Caltcues 
VAR Length 
SEO 
OR fe=-TRUE 
IF | 
== Nedacive 
String (Svteed — se 
SEQ | 
Sian s= =e 
Start := 2 | 
Length := string [BYTE 0] - l 
-- positive 
Strincget ste) bee 
SEQ. 
Sign := 1 
Sec 
Length := string [BYTE 0] 
-- convert to integer 
se Index = [Start FOR Length] 
EO Da: Gant: 
> , 
Digit := string [BYTE Index] 
('0' <= Digit )eiNDek Digise <= (lols me 
integer := (integer * 10) = (Digi 
U 2 
OK := FALSE 
integer := integer * Sign 
SKIP = 


-- PROC rem.write.number (VALUE integer, root.number) 
mane RARKAKKARKRAAKARAAKRARAKARKRKAARARKAKAARRARRRARRAKRRRARKARKRARKRRKE 


--- DESCRIPTION: This PROC outputs a signed inteqersyvalue tom, 
--- the screen. It left justifies the number, so that if you * 
--- need it right justified, use the dec.to.ascii and then * 
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--~ the Were. String FOuUEInes. * 
--- It uses the following aot : 
-7- -234193 \---> -234193 * 
=<= 1496 “<=> 149 * 
~-~ USAGE: write.number toner Je) * 
--- write.number(13 * 

x 


BemeReMank:s Lt, £5 TO BE USED JUST IN REMOTE TRANSPUTERS 
mame KAKKKKKAKKKKKAAKKAKKAARKKAAKKAKKARAAKKARKARKARKARKARKKKKKAKKAR 


PROC rem.write.number(VALUE integer, root.number) = 
DED mMain.int = - sa 483648 : 
DEF max.digits = : 
VAR number, j: 
VAR order.of. digit : 
Wen digit {BYTE 12 
VAR string [BYTE 12] 


number := riteger 
oC ae wdigit := Li 
I 


number = 0 
send (40, Boowenumper , 109!) 1,1) 
number = min.int 
send (40,root. number, 2147483648" 1,11) 


ae 
TF 
number < 0 
SEO : 
number := - number 


Seigler bee0 | a=. =" 
UE 


String (BYTE Ojsc= ' | 
WHILE number > 0 


SH 
Adee [BYTE order.of. eae = (numbDe haweOn + Or 
number := (number / 10) 
Ordeuwor,Gidit 3;= Order.of.digit - 1 
eroes = [ (order. of.digit+1l) FOR (max.digits-order.of.digit) ] 


string ae ieee =sCacgaite (BYTE 2) 


--= number > 0 


ae 
eee (40, POOL.numoer string, 0,]) 


Some soc rem. clear.screen (VALUE root.number 

mm KKKKKRKRKKKKRAKKKKKKEKKRKKRKKRKKKKKKRAKRRKARKKKKEKKRAAKKRAKKKAKRE 
--- DESCRIPTION: It clears the screen and homes the cursor. * 
foe) USAGE: clear.screen 


Semen ehakK: IT 15 TO BE USED JUST IN REMOTE TRANSPUTERS a 
mmm KAKKKKAKKAAKKKKAKAKKAKKKAAKKKKKARKAKAKKAAKAAKKKAAARAAAKKAAKKKK 


PROC rem.clear.screen (VALUE root.number) = 
oe0 sleleobelem (Psvaya 7 i) = 


string (BYTE 0 = esc --- clear screen sequence 
string [BYTE Ll} := bs 

Setrng (BYTE 2 = 'Z' 

String | BYTE 3 = fg! 

string [BYTE 4] := -~~ home cursor 

string [BYTE 5} := '[' 

sening | BYTE 6 = 





send (40,root.number,string,0,7): 
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-- P 


PROC 
VA 
VA 
SE 


-- Pp 


ROC rem.pos.cursor (VALUE line, column, root.number 

KAAKAKKKKKAKKAKKKKAKKKAKKKKARKAKKAAKKARAKKKAKAKKKAKKKRKKRKKKKKKK 

DESCRIPTION: Positions the cursor in a specified line and* 

column. We have used the ANSI escape sequence 

ESC [Line;Column H. 

USAGE: pos.cursor (8,30) * 

REMARK1: Valid values for line are 0 up to 24 x 
Valid values for column are 0 up _to 80 * 

REMARK2: Values out of the above range will cause us 
unpredictable results. si 

k 


REMARK3: IT 1S TO BE USED JUST IN REMOTE TRANSEUTERS 
KAKKKARKRKKAKKERKKARKAKKAKKKKKAKKAKRKAKKARKAKRKKAKKAKKKKKKKRKKKKK 


rem.pos.cursor (VALUE line, column, root.number) = 
R string [BYTE 8]: 
R x [BYTE 2], y [BYTE 2]: 


F 
pecs < 10) AND (line >= Q) 
BYTE 0 'Q! 
“uy 1 oyie line + #30 
ean >= 10) AND (line <= 24) 
y te 4 = fee er + #30 
yY —} 





op CAL line\10) + #30 
SKIP 
if 
eco run <"10) AND (column >= 0) 
S 
x By ie.0 |) =) 10" 
ewe = column + #30 
(column >= 10) AND (column <= 80) 
SEO 
x ee 4 = eGo + #30 
doe eh GIh aie = (column\10) + #30 
TRUE 
. SKIP 
String poy oe. Oi s—= ese 
=e gable pS AiNd, eth es ae |, 
String (BYTE 2| s= y [iBYGE ‘i 
SthiIng | BYne- 342: — y BYE. 
StGing | BYts 4 =a; 
string |BY1ls. 5) = see 4 
string [BYTE 6| := x [BYTE l 
string#|] BYTE 7e:— “ 
send Tater coer moer,String,.0,¢c)— 


ROC rem.new.line (VALUE number, root.number) 
KAKKKAKKAKAKARKRAAKAKAKAKKKKKAKKARAKKRAKKA RA RARKAAAKKRARKAKKKKKKR 
DESCRIPTION: It will skip as many lines as specified in * 
its parameters list. * 
USAGE: new.line(4) . 3 
REMARK1: Negative numbers will not give any new lines. ; 
x 


REMARK2: IT IS TO BE USED JUST IN REMOTE TRANSPUTERS 
KARKKAARAKAAKKKKKKAKKKARAAKAKKKKKKAKAKAAKKKKAKKKKRAAAKAKKRAAKRAKAKK 


PROC rem.new.line (VALUE number, root.number) = 
VAR string [BYTE 2]: 
SEQ 
ere BYTGs 0: =aer 
SEIN Byun ft = 


-- P 


See 
SEQ 1 = [0 FOR number] . 
send (40,root.number,string,0,2): 


IES 


ROC rem. space (VALUE number, roo number } 
KKEKKKRKKKK KRKEKKRKKKKEKREREERRKRAKARARRRRAERRKRRAKKKAKKE 


ARK 
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--- DESCRIPTION This procedure provides spaces for formatting” 
--- a single line. x 
--- USAGE: space(8) ; 

--- REMARK1: This routine does not provide an automatic lf 
--- after reaching the end of the line. 


--- REMARK2Z: IT IS TO BE USED JUST IN REMOTE TRANSPUTERS 
mmm KKKKKKKAKKKKAKKARKKAKKAKKKAKKKKKAKKK KKK AKKKRKAKKKKAKAKKAAKERAKKKKK 


A OO Oe 


PROC rem.space (VALUE number, root.number) = 
oe Styang (BYta 1]: 
Sening [BYTE 0] += sp 
560 i = ye FOR number | . 
send (40,root.number,string,0,1): 


-- PROC rem.tab (VALUE number, root.number) 

wee KARKKKKKAKKAKARAAKKARKKKRKAKRAKKKRRKRARRKAKAARKAAKRKARKRARKKARRAAR A 
--- DESCRIPTION This procedure provides tabs for formatting a* 
e-- single line. Each tab is equivalent to 8 spaces if the 
--- terminal is using the default set up. 

--- USAGE: tab(6) . . . 

--- REMARK1: This routine does not provide an automatic If 
--- after reaching the end of the line. 

e\ee- REMARKZ: IT [8S TO BE USED JUST IN REMOTE TRANSPUTERS 


Re. Oe ith one te, Ty ero ee eat ee el LT a ee et kee See NLU meng oe) Teme ta Molle) 1 ee Ea ae rene Eee canes cemney SemEee ROC gn N ILS eeee, TOer | 


www NKR KM KKKKREKRAKRRRAKRARRRRARKARRRRRRRRRARRRRARRRRRKRRKRKKKER 


a 


pS a, a a 


PROC rem.tab aoe number, root.number) = 
VaR StLingeiBYLE 1 | : 
SE 


SEEING eyes 0] == tab 
SEQ 1 = [0 FOR number] . 
send (40,root.number,string,0,1): 


-- PROC send (VALUE channel.id,dest.transp message | | start .byte,size) 
mn KAKKKKKAAKAKKKAKKKKAAKAAKARAKKARKKAKKKREARKKA KK RA RKARKRKKKKKRREA 

PaO EGCRIPTLON: Tt 1s an Bue roee ad syseem Goutine, and it 
--- is used to communicate between processors. It builds the 
mee meader of the a ahaha Peppem scene le as as parameters 
-==- the channel id of the. channel which is going to carry on 
--- the communications, the id of the destination transputer 
Zaeecor that message, the start byte and the size of the 

--- message to be transmitted. For every send must exist a 
“-- receive for that same channel id in the destination 

eee cransputer . 


5 a i a i a i a i aS 


Rie neem eon te ete eres es Me eee Ue er WL te Se ee ee ie ee) pe eh ek ee i ee ee he 


VAR out,message.size,header [BYTE 5 


ee 


Size-<= 0 --=- send from the start.byte all way to the end. 
ae llommettOcetoe valid tor messages up to 255 Dytes. 
eo Vem@merOn staemq0 tc Dehaves tike 1t was a 0. 


PROC send (VALUE ee ee ee start byte, size)= 


Pt eeeo de sence s=-(message([BYTE 0] - start.byte) + 1 
U 
message.size := size 


header [BYTE 1 
header |BYTE 2 


header |BYTE 4 


Meeeeee ote (sen Seo lecwustZemr OF 2560 DYLeS} 

message.size\Z56 === + remainder ) 

achanvierwn due ome any tenth from 40 up to 240 
ese en ansp === CeStination transputer 


out := route.table [dest.transp]. 
SE mges OOLELUT (chan[channel.id + out],header,3,1) --- ready flag 
out = 4 


IS3 


BYTE ySLLCEOUlC um Be eaereeraetie scds se 
St link4,message,start.byte,message.size) 
out = 
“SEQ | | 
BYTE.SLICE.OUTPUT BERTIE ce eo 
Bee eee link5 ,message,start.byte,message.size) 
out = 
SEQ 
BITE. SbueyOUlr Un Tinie header Te eae 
ae link6 ,message,start.byte,message.size) 
out = 
SEO 


BYTE.SLICE.OUTPUT pp nk? header te ae eae . 
BYTE.SLICE.OUTPUT (link7,message,start.byte,message.size) 
.OUTPUT (chan[channel.id + out],header,3,1): --- done flag 


(Sere Seemest Some ieee leek Joes eel Jn ct ae, Se MT Toe ee Cer em ee oa RO ee Oe ee AS ore SO a A 


DESCRIPTION: It is an ope raed system routine, and it 

is used to communicate between processors. It receives 
the incoming message, and provides as an output parameter 
the size or the message just received. The parameter 
channel id must have an exact match with the send 
operation which originated that message. 

JShGE: receive (70,message.in,size) 

REMARK1: The user must be familiarized with the Operating 
System Structure before using this routine. 

REMARK2: Notice that the message.length output parameter, 
must be a unity array of integers, while the message 


itself must be declared as an array of bytes. 
KRRERAAKAKRRAAAKARK RAR RAAKRRRKRAERRKARREARERKRRRARAREKRARAKAKAKKKARK 


+A A A dt a A 


EROS receive (VALUE channel.id,VAR message[],message.length[])= 

EQ 
WORD.SLICE.INPUT p chant channe rig) message ven aaa 
BYTE.SLICE.INPUT (chan[(channel.id],message,1,message.length[0]): 


== Wei dtes soc . 
== PROC rem, trek, to. came (VALUE start, stop 
KARKRKRKARKKRAKRAAKRRARRK 

a=> DESeR fr WlOhiemer & 
==¢ board.type = 


Wend orale a eo 


KRAERAKAKAAKKAAARRAKRRK AKA RE RER RRRAKRRRER 
expects the board type which can be 
Oro VAA vas) 


----> 


board. 
board. 
board. 
board. 
beard. 


Eype 
eyDe 
type 
type 
type 


es 
2 eee 
oe 
S22 5220 
q =Sac> 


BOO] 
BOOZ 
BOO3 
BOO3 
BO04 


(T414-12.5 MHz) 


(T414:15 MHz - high pr} 
(T414:1 5MHz - low pri 


and 2 signed integers eee some tick values 
obtained by an assignment of the type TIME 2? Ctimé.van 
It then outputs the corrected elapsed time in hours, min, 
sec and msec, already taking into account the fact that 
the timer wraps around when it reaches MAKINT or MININT. 
USAGE: tickk.to.time (timel, time2,31) 2 
REMARK: Although it takes care of the wrapping, it won't * 
keep track of the number of times you have completed one * 
full cycle of the timer. In order to solve this problem *%* 
= ee should record reughly the start time. For example, in* 
the VAX/VMS, the full cycle of the timer 1s 7-2 ming 

if you get the elapsed time of 5 min 7 sec 320 msec and * 
you have oe rough total time of 12 minutes, then the * 
real total time is 12 min 19 sec 320 msec. s 


REMARKZ: IT IS TO BE USED JUST IN REMOTE TRANSPUTERS = 
KA RAKKARKKKKKARKKAKAKKARKKAKKA KAKA AK KKAKKAAKAKAKAKKAAKAAKKAKAKK 


AAA AAA AAD aS 


A A A 


PROC rem.tick.to.time (VALUE start, stop, board.type, root.number) = 
-- constant definitions 
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DEF vax.sec 10000000 : --- hundreds of nsec/second 


DEF vax.mili = 10000 : --- hundreds of nsec/milisecond 
DEF bOOl.sec = 625000 : seo Of 1.6 usec/ second 

DEF bOOl.mili = 625 : --- # of 1.6 usec/milisecond 
DEF bOO3h.sec, = 1000000 : Za Ormlsec, SeCOnC 

DEF bO0O3h.mili = 1000 --- # of usec/milisecond 

DEP Dus L sec = —eto6Z5 --- # of 64 usec/second 

DEF b0031.mili = al --- # of 64 usec/milisecond 


DEF max.number.of.ticks = 2147483648 : --- maximum integer (2%**31) 
VAR elapsed.tick : 

VAR factorl, factor2 

VAR msec, tot.sec, sec, min, hr 


F 
board.type = 0 en- VAX VMS 
S/d 
actorl := vax.sec 
factor2 := vax.mili 
board.type = 1 aces 510) 0) 
SE 
aceon ¢—= DOOL.sec 
factor2 := b001.mili 
Sfolelictels ig a) emo OZ. 
SKIP --- not implemented 
board.type = 31 --- B003 in high priority 
sya ; 
Pere = b003h.sec 
factor2 := b003h.mili 
board.type = 32 --- BO03 in low priority 
Syed 
steigeell Go |a)0)0ls arty a 
factor2 := b0031.mili 
board.type = 4 ; == BO04.. 
SLE --- not implemented 


pee eco: back := stop - start 
elapsed.tick < 0 


elapsed.tick := elapsed.tick + max.number.of.ticks 
TRUE 
Sitio 
tot.sec := elapsed.tick/factorl 
igh z= tot.sec/3600 
min := (tot.sec\3600)/60 
sec := powueec Nee 
msec := (elapsed.tick\factorl)/factor2 


== output time to screen 
rem.write.number (hr,root.number) 
send (40,root.number," hr ",1,0) 
rem.write.number (min,root.number) 
send (40,root.number," min ',1,0 
rem.write.number(sec,root.number 
send (40,root.number,'" sec ",1,0 
rem.write.number(msec,root.number) 
send (40,root.number," msec",1,0): 


-- PROC dump (VALUE begin. address count, root.number 
mmm KKKKKKKKKRKEKKKEKK RK RERKEREREKEKRRERREKKEKRRRKRKRRRKRKARKKKAKAAKK 


=== DESCRIPTION: This procedure dumps the memory starting at * 
--- the given "begin.address". The value for the is 


SS 


--- "begin.address! can be either in hex or deeumoe | 
--- The count value determines how many words in memory will 
--- be retrieved. 

--- USAGE: a) dump (#80003540,100) 

--- b) dump (1024,48) 

--- c) dump (75113,1024) 


~-- REMARK1: When specifying the count value remember that 
~~~ the retrieval is done by words, not bytes!! i)” 

--- REMARKZ: If count 1s not a multiple ci 4010 witieusemure 
--- closest aeees Ue toaer. 

--- REMARK3: Negatives or zero values for count although 

--- accepted, will give you no output. 


“-- REMARK4: IT IS TO BE USED JUST IN REMOTE RTRANSEUTERS 
mae KKKKKARKKAAKAARAAKKKKKKAKAKKKAAKAKAKKKKAKAKKKKAAAKKAKKKKKKRAKKKKA 


OO OO 4 OO Oe A a 


A 


PROC dump (VALUE begin.address, count, root.number) = 
VAR word.read: 
VAR hex.value [10], hex.addr[10]: 
VAR address, align, times: 


SEQ. 
times := 0 
rem.new.line(1,root.number) 
address := begin.address 
Begs a given address 
ee tgn := address\4 
T 


address := address - align 


WHILE times < count 


SEO 
send (40,root.number,"address ",1,0) 
dec.to.hex (address,hex.addr) 
send (40,root.number,hex.addr,1,0) 
send (40,root.number," <--> ",1,0) 
SEQ 1 = (0 GOR 4) 
E 


Q 
GETWORD (word.read,address) 
dec.to.hex (word.read,hex. value) 
send (40, root.number,hex.value,1,0) 
rem.space(2,root.number) 
times := times + 1 

SKIP 

address := address + 16 

bya g Pemnew LIne VE eo aaa 


-- PROC transfer.rate (VALUE start stop board. type nr.of.bytes,VAR rate) 

a KAKKKKKKKKEKAAKKEKKKKKKK KARE RKKAKRRRKARRKKKAKRAREKAKAKEKRKKRRER 

-~- DESCRIPTION: It is basically the same routine as 

--- tick.to.time, with the only difference that it returns a * 

--- rate value in Kbits/sec instead of a time value. * 

-~-- USAGE: transfer.rate (timel,time2,31,4096, rate) * 

“-- REMARK: For further information refer to routine : 
~ 


-<= tick.to. time 
mm KR KAKA KK AKA KKKAKAKKKRAKKKKKKKARKAKKKKAKRKKKAKKAKKAKAKKAKKE 


+ 


PROC transfer.rate (VALUE start,stop,board.type,nr.of.bytes,VAR rate) = 
=e TCONSicane sdeti Melons 


DEF vax.sec =10000000 : --- hundreds of nsec/second 
DEF b00Ol.sec = 625000 : --- # of 1.6 usec/second 
DEF bOO3h.sec = 1000000 : --- # of usec/second 

DEF b003l.sec = 5G75 --- # of 64 usec/second 


DEF max.number.of.ticks = 2147483648 : --- maximum integer (2**31) 


-- variable declarations 
VAR elapsed.tick : 


136 


VAR factor : --- to convert ticks to seconds 
SEQ | 

elapsed.tick := stop - start 
Oy 


epebee aa act < 0 
elapsed.tick := elapsed.tick + max.number.of.ticks 
RUE 


SKIP . 
-- selection of correct factor iaw the board 
board.type = 0 AES RAIS 
factor := vax.sec 
board.type = 1 aa oOo) 
factor := bOOl.sec 
boamemeype “= 2 ice B=100V75 
Shile --- not implemented 
board.type = 31 --- B003 in high priority 
factor := b00Q3h.sec 
board.tvpe = 32 --- B003 in low priority 
factor := bp0031.sec 
board.type = 4 === 2004) 
Sic --- not implemented 


-- rate calculation 


if 
board.type = 32 . 
rate := ((nr.of.bytes*8)*factor)/ (elapsed. tick*1000) 
“-- operation is done this way to keep precision ok! 
TRUE 
rate := ee eee epee es 7/1000) elapsed. tick | 
--- operation is done this way in order to not exceed maxint 
Soon eminem aE Ot . | 
25 Lee ay 8 due to 8 bits per byte . 
--- divide by 1000 to have the tranfer.rate in kbits/sec 


Sivl >: 


maeeeOC operating.system 
Bmee Operating.system = 
=- PROC input.handler 
PROC input.handler = 
-- variable and constants declarations 
VAR headerO [BYTE 5], 
headerl |BYTE 5], 
heacer2 {BYTE 5], 
header3 {BYTE 5], 


buffer.inO {BYTE max.block.size 
DUrrer sealer ls max.DLOcK.size 
butter wnesloels max.block.size 
buffer.in3 | BYTE max.block.size 


Blpeksscizeull| outd, 
plock. Sizer) lk), outl, 
Breck.sizez|i |) .outZ, 
Plockesauzesl li. outs: 


SEQ 
aa INitaalazing che buifers 
eae = [0 FOR max.block.size] 


~~ *-» ss © 
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buffer.indO [BYTE i = 'Q! 

butter anlar 

buifter-in2d (BYTE a) :=32) 

buffer.in3 |BYTE i = 3) 
SKIP 


PAR 
WHILE TRUE 
-- listen to linko 
SEQ 
a Eece ad Ene ue deers . 
BYTE. SLICE Neun fannie. 


a Be salent the ere 
block siz60 (Gi: Ceasar 1])+headerO(BYTE 


27  OULle hie ene (liao: 
BYTE .SLICE.INPUT {linkO ,buffer.in0,1 block sizeuane 


iia 


he nTBYTE. 4) 1s 


to be bypassed 
headero [BYT ee 
Su 


<> this.transputer 


-- finding the best link to output that message 
outO := route.table (headerO [BYTE 4] ] 


-- outputing to the required ae 


--- request flag thru chan 4, 35, 7 
ee JSLIGS.CUIPUL( chanloucey Re sceeon 3 1) 
ole 
outdo = 4 
SEQ 
BYTE .SLICE.OUTPUT creme 
BYTE .ShEreGe OUTPUT link4 , DUETer amon, 
block .sizeuucur 
outO = 5 
SEQ 
BYTE.SLICE.OUTPUT ae ,yneader0,1,header 
BYTE .SLICE.OUTPUT (LinkS ,buffer. ind, oe 
bleeke size0[0]) 
outdo = 6 
SEQ 
BYTE.SLICE.OUTPUT eae pyheaderO,1,header. 
BYTE.SLICE.OUTPUT (link6é,buffer.in0 
bicck. size0[0]) 
outdo = 7 
SEO 
BYT= .SLEGs .OULeUT Satie: headerO,l1,header. 
BYTE .SLICE.OUTPUT (lLink7 biltmerne ino, Le 


block. size0[0]) 
--- release flag 
BYTE .SLICE.OUTPUT(chan[out0] ,header0O,3,1) 


-- the message is for this transputer 
headerO (BYTE 4] = this.transputer 


SEQ 
== Passing the size of the message (block.size0[0]) 
WORD.SLICE.OUTPUT (chan[headerO[BYTE 3 
block.size0,0,1) 
assing the message itself 
BYT FobLGe Out Un sce an{header0 (BYTE 3|] ,buffer.1nGeae 
Dilock. $1ze0(0}) 
WHILE TRUE 
-- listen to linkl 
SEQ 
a Sale eee the header 
BYTE.SLICE.INPUT (linkl,headerl,1,header.size) 
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size) 


.size) 


size) 


-- decodin 
block.size 


{| 


-- bufferin 


0] 
the 


Eyl sow lesmiNe gm. (tak 


IF 
-- the messa 
neaes et [BYT 


7 


-- finding the best link to out 
route .tabl 


far bhegk 


the block siz 
9 (PIE os 


7 
headerl{BYTE 1])+theaderl[BYTE 2]) 


TORS EE . . 
fewerer. ini, plock.sizel(0]) 


is to be bypassed 


4] <> this.transputer 


put that message 
e {headerl [BYTE 4]] 


-- outputing to the required link 


--- reques 
Belk eobick 


--- releas 
BYTE.SLICE 


a° 


-- passin 


-- the messa 
pes dent [Bye 


WORD.SLICE.OUTPUT (chan[headerl 


z.0 


-- passin 
BvGeeouLle 


WHILE TRUE | 
-- listen to link2 
SEQ 


-- receiving the 
BYie oot LereerN el Ua 


3 | 


-- bufferin 


-- decodin 


bleekasizeZz( oO) 


the 


BY Ibe oeleGh. INPUT (link 


IF 
-- the Resscue 
neeceEe tee 


-- finding the best link to out 
:= route.table [ 


outz2 


is 
4 | 


the block siz 
s= ((256 * 


t flag thru chan 14, 15, 16 or l 
OUTPUT (chan[10+outl] ,headerl,3, 


| 
| 


; 
1) 


- SLICE 
eo orCr 


FOUTE OL 


link4 ,jheaderl ,1,header. 
BOUL UT 


link4 ,buffer.inl,1l, 
block.sizel[0Q] ) 


size) 


— SEL e oD 
Pop Len 


SOUTPUL 


linkS5 ,headeri ,1,header. 
FOUL Ee UE 


lamico, Ourrer.ini ,l, 
block.sizel[0]) 


size) 


TOUben. CULPUT 
fo LCE. OUIPUT 


link6 ,headerl,1l,header. 
lineereuerer. inl, 1, 
block.sizel[0]) 


size) 


Soler 
Po oner 


Pa 
JU e 


pOUrr UL 


link? ,headerl,1, header. 
OUTPUT 


een 
block.sizel[0]) 


Mchan(lGreutl) ,headent 3.1) 


size) 


S 
0 


fom eats se ransputer 
thas. Eransputer 


the size of the message (block.sizel[0]) 
[avTe 31] 


b ock.sizel,0,1) 
he message itself 


UTPUT (chan{headerl [BYTE 3]],buf 


fer.in., 
I plock.s2zel {0 


header 
(link2,header2,1,header.size) 


2 
header2[BYTE 1])+header2[BYTE 2] ) 
messa 


e 
Pee eece nom mige size? (01) 


is to be bypassed 


4] <> this.transputer 


de that message 
header2 [BYTE 4] ] 


fee 


~~ outputing to the required link 


~-- request ae thru chan 24) 255) Zemoez? 
Bene “SLICE. OUTP T(chan{20+out2], header2, 3 7) 
out2 = 4 
SEQ 
BYTE .SLICE.OUTPUT oe ,yneader2,1,header.size) 
BYTE.SLICE.OUTPUT (link4,buffer. in2, ii 
biloeic size2(0]) 
out2 = 5 
SEQ 
BYTE .SLICE.OUTPUT yanks - ,yneader2,1,header.size) 
BYTE. .SLICE.OUDPUT (links bueeene in2, Abe, 
bilcck. size2(0]) 
out2 = 6 
SEQ 
BYTE .SLICE.OUTPUT ee ,header2,1 sheade ta 
BYTE .SLICE.OUTPUT (link6é sureen. in2, 
Dock. ero 
out2 = 7 
SEQ 
BYIE.cLICE-OULPUL peas ,yneader2,1,header.size) 
BYTE .SLICE OUTPUT (link7 suerte: in2, a 


--- release fla 


SPIED, oye e/a 


block. ‘$ize2(0}) 


OUTPUT (chan[20+out2], header2,3,1) 


~~ the messa S. i for this transputer 


header2 [BYT 
SEQ 


WOR 


assin 
~SLIC 


assin 


BYT -SLICG 


WHILE TRUE 
-- listen to link3 
SEQ 
-- pecesvang the 
BYTE. sLIGE i 


= this.transputer 


the size of the messa 
.OUTPUT (chan[header2 


the message itself 


[BYTE 2 
block.size2,0, i) 


FOULRUeK c SECS Dee EE Elm )s 


header 


-- ae ita block s 


block.size 


-- oueee eS the 
BYTE.~SLICE -iNPUs 


IF 
header3 [BYT 
Sy 


-~- the message is to be b 
4] <> this. 


-- finding the best link to 
route.table [header 


out3 := 


messa 


buffer. 
bilock. 21 562 10a 


PUT (link3, ST eee 


2 
(lank? buffer. inaemebiee ede een 


assed 
ransputer 


ble at message 


3 (BUTE 4) ] 


-- outputting to the required link 
--~ request fla 
OUTPUT (chan[30+out3] , header3,3,1) 


Bite coLer. 
IF 


»~ SLICE. 
» SLICE 


thru chan 347¢es- 


OUT Ur: 


SOUL RUE. 


| 


3670 3! 


3 2 sy size2[0]) 


:= teres “k header3(BYTE 1])t+theader3[BYTE 2]) 


link4,header3,1,header.size) 
link4, ‘buffer. in3, le 


‘block. size3(0]) 


. SLICE .OUTPUT aie ,header3 ,1, hee size) 
SLICE ,OUTEUR 


Links burrer: in3, 
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block.size3[0]) 


BYtE.SLICE-OUTPUT (link6é,header3 ,1,header.size) 
BYieeocles.OULPUL (linkeé, ‘buffer.in3 
‘block. size3[0]) 


BYTE .SLICE.OUTPUT pranks ,yheader3 ,1,header.size) 
BYTE.SLICE.OUTPUT (link? ,buffer.in3 
Dlocie size3(0]) 
--- release fla 


BYTE. SLICE .OUTPUT (chan[30+out3], header3,2,1) 


-- the message is for this transputer 
header3 [BYTE 4] = this.transputer 
SEO 


-- passing the size of the message (block.size3[0]) 
WORD.SLICE.OUTPUT (chan[header3 [BYTE = 
block. size3,0,1) 


assing the message itself 
BYT "SLICE SOUT Ore Coan | neaders [S:iees| | burter.in3, 
melock. 31ze3[0]) : 


== PROC output. handler 
PROC output.handler = 
-~ local variable declarations 


VAR flag4 [BYTE 2 
VAR flagS [BYTE 2]: 
VAR flag6é [BYTE 2 
VAR flag7 [BYTE 2 
PAR 
WHILE TRUE . 
ALT i = Gi FOR max.1o.channels|] 
chan [(10*1) +4] ? flag4 Retest 0] --- for ates 
BYTE.SLICE.INPUT (chan [(10*i) +4], flag4,0,1) 
WHILE TRUE 
ALT j = i FOR max.io.channels| 
Ghemmucresg) +5) ° £lags Wee --- for links 
BYTE.SLICE.INPUT (chan [(10*j) +5],flag5,0,1) 
WHILE TRUE | 
ALT k = a FOR max.io.channels| 
Ghanwi(l0nls) +6] ? flag6 rae QO] --- for link6é 
Paes ee INrun (chan |—(10*k) +6], flagé6,0,1) 
WHILE TRUE 
ALT 1 = ree FOR eee oc nonne 7S)... 
Ghani er iy +7). 2 flag? oe 0) == Link7 
BViSeseLCa.ikNeul (chan (10%1) +7j, eisg7, Oe): 
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me main body of the operating system 


-- receivin 
route. 
route. 


route 


route. 
route. 
route. 
route. 
route. 
route. 
route. 
FoOuUce:. 
route. 
ZOuULe. 
route. 
route. 
route. 
route. 
route. 


PAR 


output.handler 
input.handler: 


the peers table 


table{0 ie. 
table/[1 := tl 
. tablet 2 := t2 
table|3 := t3 
table|4 := t4 
table|[5 2= 5 
tablel6 s= £6 
Page 7 := t7 
tabie 8 := ¢t8 
table] 3 = ¢9 
table/i0 = Ee 
table{11l -= tll 
table/{12 = 12 
table/13 = t13 
pene := ¢14 
table}1i5 = EEs 
Saree := t16 
tablej{17 | >= t17 
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output 
output 
output 
output 
output 
output 
output 
fe bome.bue 
output 
output 
output 
SUEDUE 
output 
output 
OUCPUE 
output 
output 
OUEDUE 


link 
Jah 95s 
link 
link 
Jeaigyys 
link 
link 
Iestyuilss 
Pak 
link 
link 
link 
as 
link 
1B 6: 
Lannis 
lank 
link 


transp 
transp 
transp 
EISEN ORE! 
transp 
transp 
transp 
transp 
Eeanee 
transp 
transp 
transp 


transp. 


transp 
transp 


transp ; 


chanse 
transe 


APPENDIX F 


THE EVALUATION PROGRAM FOR THE OPERATING SYSTEM 
(EVAL_OS.TDS) 


-~ PROGRAM os.evaluation 
-- os.evaluation 
“= SC PROC hostproc 
-- PROC hostproc(CHAN A,B,C,D,E,F,G,H,VALUE this.transputer,route.table) 
PROC hostproc(CHAN A,B, C,D,E,F,G,H, 
VALUE this.trans uter, 
EOMEL E22 t3..f4 tS, tOe ey EO eos 
t10,¢11,t12,t13,t14,t15,t16,t17) = 


-- root _os.tds 
mm KKKKAKKKKKKKKKRAKKKAKKEKAKKAKAKAKKAKK RAK ARR RRA RII OK 


--- In this place should be imbedded the filed fold * 
--- ROOT_OS.TDS, which contains the source code of the x 
=S5 gay ene system For tne nook Eransputer - x 
--- is fully documented in Appendix x 


aan ae ee ee I RIK RRR ARR RARRRRRKRARR RRR KIRK 


-- PROC user.interface 
PROC user.interface =. 
Beeconstant ana variable declarations 
Oem sizetable = TABLE [| 1, 2, 4, 8, 16, 32, 64, 128, 256, 
Sia O24. 1280, 2048 , 4096 |: 
DEF nr.of.sizes = 14: --- # of entries in the above table 
DEF maxblock.size = 4096: --- max from the above table 
VAR DbufferO [BYTE maxblock.size + 1], 
Ueto rta (So aleemaxo lock (S126. tail), 
buffer2 [BYTE maxblock.size + 1}, 
buffer3 {BYTE maxblock.size + l 


VAR run : 777 number of runs made (RUN #) 
VAR answer eee Zee === Beer SEGiGtGcu tim catrinte Or Quit 
VAR repetition -<-- umber of times to carry each xfer 


VAR dummy0[1], dummy1 [1], Bateau dummy3 [1] 


-- PROC write.header 
PROC write.header = 
ee the header of the output table 


run := run + l 
clear.screen 


write.string me # '') 

write.number (run) 

space (3) 

write.string ("CPUs IDLING i") 
space(2) 

Uahte seg ng Bynenoeleh. input/output" ) 
space (2) 

write.string ease easy = '')/ 

write.number (repetition) 


new. line (2) 

write.string Nene FOGmeLIN@«2OUT Z2ZIN SOUL SIN ')} 
write.string ("40UT 4IN 4INOUT'"') 

new. line(1): 


~- PROC transfer 
PROC transfer = 
-- variable declarations 
VAR block.siZe, 
actual. rate, 
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cho (byte 2] ,chi{BYTE 2],ch2[BYTE 2]/,chejey tae 
timeO[4 
timel/4 


or 
Sg zo = [0 FOR nr.of.sizes] 


-- making the table after each io operation 
block.size := sizetable{i] 

Write.number (block.size) 

ba 1) 

-- output to one channel 

actual.rate := 0 

SEE j} = {1 FOR repetition] 


a ee (90,0, tees 

TIME ? timed [0 

send (90, 0,buffer0,1,block.size) 
TIME? time1 {0 


] 
transfer. rate(time0([0] timel{Q], 1,block.size, rate) 


see seen rate := ((actual. rate k (4 1)) + rate)/j 
write.number (actual.rate) 
tab (1) 


-- input from one channel 

ee rate := 0 ae 

SEE ee {1 FOR repetition] 
EQ 


He (90).0; Var 
TIME 2 timed{0 
receive(50,buffer0, dummy0 ) 
TIME ? timel{0] 
transfer. rate(time0[0] timel[{0], 
actual.rate := eos rate * ( 

SKIP 

write.number (actual.rate) 

tab (1) 


-- output to two channels 

actual. rate := 0 

SEO 2 {1 FOR repetition] 
E 


ock. size) games 
) + rate 73 


send ee, a lee) 
send (100 Ha i ale lp 
Tine < timed{0] 
PAR 
send i00 4 ,O, buefero .1 block scaze. 
send(100, bufferl, 1,block.size) 
TLE 2 secu 0 
transfer. rate(timed{0] aor ie block.size rate) 
cop aus erate := (( ice co rate =-1)) + rate)/j 
SK 
Write.number (actual.rate) 
Galoracd 


-- input from two channels 
SCtua Pveawem: a0 — 
sera j = {1 FOR repetition] 


PAR 
Send (9Or0e "a. hai) 
send (100,1,"a ",1,1) 
TIME ? timeO(0] 
PAR 
rece ce ee pio} 86S af )10) pee 
receive(60 ,bufferl,dummyl 
TIME 2 t2mer0l 
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transfer.rate(time0O[0] time1[Q],1,block. size,rate) 
actual.rate := ((actual. rate * (j-1)) + rate)/j 


Sys 
write.number (actual.rate) 
tab (1) 
-- output to three channels 
actual.rate := 0 
SEQ j = [1 FOR repetition] 
SEQ 
PAR 
send (90, 24 Wa 1 ia 
send 100, Ma Wa 4 
senan¢ ilo. 5! re el arent 


TIME ? time0(0] 

PAR | 
send(90,0,buffer0,1,block.size) 

send RGHMSTIEEEEDGIE loclicize) 

Seng¢ive surter2? 1,block.size 

TIME ? timel[0 

transfer. Roe ee taad rece ee ,L,block.size,rate) 


: pogeuat. erate := ((actual.rate (j- -1)) + rate)/j 
Sie 
write.number (actual.rate) 
tab (1) 
-- input from three channels 
actual.rate := 0 aa 
SEY 3 = {1 FOR repetition] 
EQ 
PAR 


send (90,0,"a ",1, a, 
send 100, 1,"a oo ee 
send (110, a wa, eee 
TIME ? timed(0] 
PAR 
receive(50,buffer0,dummy0 
Hecelve og /bufferl, dummy 1 
receive(70,buffer2, dummy 2 
TIME ? timel[0] 
transfer. See ae time1[0]/1 ib gosh 
actual.rate := (actual. rate * (j -1) 
Shr 
a - ..... 


ock.size,rate) 
\ + rate)/j 
tab 


“= output to f?our channels 

AGrtianegete = 0 — 

SEQ = {1 FOR repetition] 
S 


PAR 
senda (90,0,"a "oie 1) 
Sena Loonie" a " Lod 
SencecelOe? Mag 1) 
Secale mesa tod 

TIME ? timeO[0] 

PAR 
send(90,0,buffer0,1,block.size) 
send 100, i PoUttem@iamunDlock.size 
send(110,2,buffer2,1,block. size 
send(120,3 ‘buffer3, 2 ‘block.size 

LIME ? timel 0 


transfer. rate(timed[0] een 1 ,block.size, rate) 
sip erate := (( (actual. rate j-1)) + rate)/j 
write.number (actual.rate) 
tab (1) 


-- input from four channels 
actual.rate := 0 
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send (90,0,"a ",1,1) 
send (100,1,"a “Sr 
send (110-2 as. 1 
send (120,3, "agar 
TIME ? timeO[0] 
PAR 
receive(50,buffer0, dummy0O 
receive(60 ,bufferl, dummy! 
receive (0, putrenc, cum 
receive(80 ,buffer3,dummy3 
TIME ? timel[0]_ | . 
transfer.rate(timeO[0],timel(0],1,block.size,rate) 


ofc Uae ce := ((actual.rate * (j-1)) + rate)/j 
write.number (actual.rate) 
tab is) 


-- all output and input in parallel 
actual.rate := 0 RG, 
SEQ 3 = {1 FOR repetition] 


send (90,0,"a "-1,1) 
send (100 7152 oe 
it 
1) 


TIME ? timed[0] 


send($0,0,buffer0,1,block.size) 

- gsend(100,1,bufferl .1 ,block. size 
send(110,2,buffer2,1,block.size 
send(120,3 ,butter3,1, block siz) 
receive(50,buffer0, dummy0 
receive(60,bufferl, dummyl 
receive(70 ,buffer2,dummy2 
receive(30 buffer3,dummy3 

TIME ? timel[0] | 

transfer.rate(time0(0] ,timel(0],1,block.size,rate) 

26 areca := ((actual.rate * (j-1)) + rate)/j 
write.number (actual.rate) 
new. line(1) 

Sy sll) 

new.line(1): 


-- main program 


S£0 eo | 
-- some variables initializations 
run := 0 
answer |[BYGEel | = "Zz 
Pepe Gleeson -—) 20 


== Initialization of busters with by eco 
SEQ k = {1 FOR maxblock.size + 1] 


Jel 
ufferO {BYTE x 


=e G 
bufferl (BYES =k a= 
buffer2 |BYTE k| := ck 


butters (bey ie. k 
SKIP 


-- program explanation 

elear seneen aa . 

write.string (" This is an Evaluation Program for the Transputer") 
new. line(2) . ; 
write.string ('" The table presents transfer rates in Kbits/sec") 
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new. line(1) . . . 
write.string (" for 14 block.sizes in 9 channel combinations ") 
new. line (2) a . 

Wiettemotimircga«  [YPhe«Y)homeimeyou want to use it ') 

new. line(1) 

Write.seming (" (N)O if you want to quit ") 

new. line(1) 


-- validate answer 
WHEE ((answer [BYTE 1] <> 'Y') AND (answer [BYTE 1] <> 'N')) 
S 


write.string ('' Type Nowe choice") 
Keyboard ? answer [BY Ee] 
capitalize (answer 


screen[{4] ! 
Screen ! answer [BYTE 1] 
screen(4| ! ‘a! 


new.line(1l) 
WHILE answer [BYTE 1] = 'Y' 
SEQ 


SS wietncecnenm cds bes nedcde rt 
write. header 


-~ running the actual transfer program 
transfer 


-= prom pang for new run 

answer TBYT Pies= 22! 

-- another run ? 

WHILE ((answer [BYTE 1] <> 'Y') AND (answer [BYTE 1] <> 'N')) 
SE 


--- to make the next loop be executed 


write.string ('' Do you want another run ? (Y)ES or (N)O ") 
Keyboard ? answer Ware 1 | 
capitalize (answer 


screen[4] ! ‘a! 

Screen ! answer [BYTE 1] 
screen{4] ! ‘a! 

new. line(1) 


PAR 
send (90,0,answer,1,1) 
send (100,1,answer,1,1l 
send (110,2,answer,1,1l 
send (120,3,answer,1,l 


-- eXiting the program 
Cleéar.screen 
write.string (" Press reset button to get back to VAX/VMS ") 


PAR 
operating.system 
user.interface: 
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-- SC PROC trans 


-- PROC transfer0.b003 (CHAN A,B,C,D,VALUE this.trans 


PROC transfer0.b 


fer0.b003 


003 (CHAN A;B,C,D, 
VALUE this.transputer, 
tO,tl,t2,t3,t4¢,t5,t6 t7, co ee 


t10,tll1,t12,t13,ti4,ti5, tionemeee 


puter,route.table) 


-- remote _os.tds 


mmm KKKKKEKKKAKKKKAKAKKKKKAAAKAKKKKKAAKAAKKKKKRAKARKKKKKAKAKKAKKKKK 


--- In this place should be imbedded the filed fold 2s 
--- REMOTE_OS.TDS, which contains the source code of the i" 


y documented in Appendix E 
man KKAKKAKAKAAKKARKARKARKAKAKKAR 


-- PROC userd 
PROC userO = 


-- constants and variables declarations 


DEF sizetable = TABLE [ 1, 2, 4 


=== poten ae system for remote transputers. 
be LS llen 


* 


RRNA NKKRARR RAN KAA RAR AA AA 


8, 16, 32, 64,128, 256, 512, 
1024, 1280, 2048, 4096 ]: 


DEF nr.of.sizes = 14: --- # of entries in the above table 
DEF maxblock.size = 4096: --- max from the above table . 
VAR answer [BYTE 2] : “--- user's cholce in continue or quit 


VAR dummy0([1] 
VAR repetition 


== PROC transier0 
FROC transrerd = 
== Variable declarations 
VAR Dlock.size, 
ENO Eye zi: 


VAR bufferO [BYTE maxblock.size + 1]: 


SE 
= initialization of buffers 
Bee k = [1 FOR maxblock.size + 1] 


EQ 
bufferO [BYTE k] := '0' 
SKI 


a = [0 FOR nr.of.sizes] 
lock.size := ee eet 
== Input and outpuc hanging 

== input roOmeonescuanie 
ete } = [1 FOR repetition] 
EQ 
receive eee 
receive 
== “OUlEpUL -tOpOnescnanme: 
sate = [1 FOR repetition] 
ae 
receive (90,ch0,dummy0 


SKIE 


eee Aree ec bio meet 


a=, 1NPUCet rom cCwomenanne ls 

sears = {1 FOR repetition] 
receive ose an 0) 
receive 

SRLE 


== output to two changers 
SEQ 9 = (1 FOR repeticion) 


eeu (90,ch0, dummy0) 
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fe 
90,buffer0, dummy0) 


90,buffer0O, dummy0) 


wa Or Oe Eero lablock.size) 


== input from three channels 
ane = [1 FOR repetition] 


receive Pe oueee eee: 
receive (90,buffer0, dummy0) 


=="GutpUt to three channels 
ey = {1 FOR repetition] 


receive one eam 0 . 
send(50,10,buffer0,1,block.size) 
le 


--S nbuc ehom tour channels 
SEQ j = {1 FOR repetition] 
SEO 


receive Reece esc ar 
receive (90,buffer0, dummy0) 


-~ output to four channels 
SEQ 3 = {1 FOR repetition] 
SEQ 
receive (90,ch0,dummy0d 
Peete usicrO 1,2 ock.size) 
S 


[ae LOULDUG and input onoparallel 
eee = [1 FOR repetition] 
S : 
receive (90,ch0,dummy0) 
PAR 
receive (90,buffer0,dummy0) | 
send(50,10,buffer0,1,block.size) 
SKIP 
Sree 


-- main program 
repetition := 20 
answer[BYTE 1] := 'Y'! 
WHILE answer|BYTE 1] = 'Y' 
JB0 
transfer0 
receive (90,answer ,dummy0) 


PAR 
Doeravcsang.syscem 
userQ : 


149 


== 5¢ PROG Eransteae Dove 
-- PROC transferl.b003 (CHAN A,B,C,D, VALUE this.transputer, route.table) 
PROC transferl.b003 (CHAN A,B,C,D, 
VALUE this.transputer, 
tO, tl, t2Z7es7't, t5, tG5cy coe 
t10,t11,t12,t13,€14>t15, etomee 


-- remote os.tds 
mm KK KKKKAAKKKKRAKEKKRAKKRKAKKRKREKRKKRKEKKKRRAKKKKREKRKKKEKRKEKK 


--- In this place should be imbedded the filed fold * 
--- REMOTE_OS.IDS, which contains the source code of the * 
sk tS) aa system for remote transputerce ‘a 
--- [Tt is fuily documented in Apecicense. x 
man RAKKKKAKAKAAKRAKKKERAKKKAKKKKAKRAKK RK AAKKAKRKK ARK RAKRARK AK 


S2),.2R0C User 
PROC diserl — 
-- constants and variables declarations 
DEF sizetable = TABLE | 2) 02; 540 slooce See 250, Ooze 


. 1024, 1280, 2048, 4096 |: 
DEF nr.of.sizes = 14: --- # of entries in the above table 
DEF maxblock.size = 4096: --- max from the above table 
VAR answer [BYTE 2] : --- user's choice in continue or quit 


VAR dummy0[1] 
VaR? (epers Elena: 


-- PROC transfer0O 
PROC transferO = 
-- variable declarations 
VAR block.sizZe, 
Cho 1B Y 0h @2|-: . 
VAR bufferO [BYTE maxblock.size + 1]: 


So 
2 initialization ofseburrers 
oe k = [1 FOR maxblock.size + 1] 


E 
Bufferd [BYTE k] := ‘0! 
Shier 


oe eee = [0 FOR nr.of.sizes] 


lock.size := Fecagsens tp 
-- input and output handling 
== INDUt from c.oecnanne ss 
SEQ j = {1 FOR repetition! 


~e 


SEO 
receive Siegen eee oe 
eee ae 100 ,buffer0O, dummy0) 


== OULDUEE CO) CyOsenanme ts 
SEQ 3 = [1 FOR repetition] 

SEO | 

receive (100,ch0,dummy0O) 
{send(60,10,burferd,1,5lock.size) 


ae 


== input from ythyeemenanheds 
SEED = [1 FOR repetition] 


receive oc eete cous 0) 
Becccue 100 ,buffer0O, dummy0) 


== OUtpUS to threesemannels 
eke j = [1 FOR repetition] 
EQ 
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receive (100,ch0, Be ie 
eg eenene, PLO, buffer0 lock.size) 


-- input from four channels 
ce j = [1 FOR repetition] 
ee Dak pano- ae 
receive (100,buffer0,dummy0) 
-- output to four channels 
SHES 3 = {1 FOR repetition] 
receive (100,ch0,dummy0) 
one 10, buffer0,1,5lock.size) 
J 
-- all output and input in parallel 
ey j = [1 FOR repetition] 
eee ive (100,ch0,dummy0) 
PAR 


receive (100,buffer0,dummy0) 
send(60,10, buffero, 1 bloc Peers 


Ski 
SIieir 
-- main program 
SEQ ms 
repetition := 20 
answer [BYTE rt il) a 
BYTE i] = 'y! 


WHILE answer 
55) 

transrer0 

receive (100,answer,dummy0) 


PAR 
operating.system 
userl : 
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== SC PROG transrerZ cous 
-- PROC transfer2.b003 (CHAN A,B,C,D,VALUE this.transputer,route.table) 
PROC transfer2.b003 (CHAN A,B,C,D, 
VALUE this.transputer, 
tO,tl,t2,t3,t4,t5, tent) eae 
t10,tll,t12,t13,tl4 cis ciomeu. a= 


-- remote_os.tds 

mann RAKKRRAREKAKKAKRARARAKRKAKARARAKRARARAERARARKARAERKARARKEREK 
--- In this place should be imbedded the filed fold x 
--- REMOTE_OS.TDS, which contains the source code of the * 
--- operating system for remote transputers. = 


--- It is fully documented in Appendix E. * 
mn RAAKKKAKAKAKAKKKAKKARKAAKKAKKAKARAAKKARKRARARARARARARAAARKRK AK 


-- PROC user2 

PROC user2 = 
-- constants and variables declarations 
DEF sizetable = TABLE [ 1, Z, 4, 8, 16, 32, 64, 128,) 256, S12 

1024, 1280, 2048, 4096 ]: 

DEF nr.of.sizes = 14: --- # of entries in the above table 
DEF maxblock.size = 4096:  --- max from the above table . 
VAR answer [BYTE 2] : e-- user's choice in continue or quit 
VAR dummyO[1] : 
VaR, repeeleron 


-- PROC transfer0O 
PROC transfer0O = 
-- variable declarations 
VAR block.size, 
cho [BYTE 2]: a: 
VAR bufferO [BYTE maxblock.size + 1]: 


SE 
eA initialization of buffers 
SEQ k = [1 FOR maxblock.size + 1] 


E 
Puffero [BYTE k] := '0O! 
KIP ; 


er i = [0 FOR nr.of.sizes] 
E 


lock.size := sizetable(i] 

-- input and output handling 
== Input frome cimeescnannens 
Be = [1 FOR repetition] 

Q 

receive cigeae re eon 0) 
Seg Coes 110,buffer0O, dummy0) 


Gh 


== OUGDUL CO three Cihammels 
aEY j} = [1 FOR repetition] 
EQ 


receive (110,ch0,dummy0) | 
send(70,10,buffer0,1,block.size) 
SEE 


-- input from four channels 
SES j = [1 FOR repetition] 
E 
receive ate cue uae 
eee 110,buffer0, dummy0 ) 


-S,OUCDUL Co foun senannerrs 
Seg = (1 FOR repetition] 
Q 
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receive Aa ae eae) . 
peace 2 ,PUEECr OL, lock.size) 


-- all output and input in parallel 
aoa = {1 FOR repetition] 


Beceave (110,ch0,dummy0) 
receive (110,buffer0O,dummy0) 
send(70,10,buffer0,1,block.size) 
Siw er 
SKIP: 


-- main program 
SEQ 


repetition := 20 
answer [BYTE rt := 'Yy! 
WHILE answer|BYTE 1] = '¥Y'! 
SEQ 
transfer0 


receive (110,answer,dummy0) 


PAR . 
operating.system 
user2: 


Iss 


== SC PROC transters. 500s 
-- PROC transfer3.b003 (CHAN A,B,C,D,VALUE this.transputer,route.table) 
PROC transfer3.b003 (CHAN A,B,C,D, 
VALUE this.transputer, 
t0,t1,t2,t3,t4,t5,66  comeee coe 
t10,tl1,t1Z2,t13 el4ayers olor oe 


-- remote os.tds 
mm KK KK KRREKRKREKKKRRRKARKRRKKRR RRA RRR RR RAKRKRKRKKAKKRKAKKKKEKE 


--- In this place should be imbedded the filed fold x 
~-- REMOTE_OS.TDS, which contains the source eode ot srncmue. 
=s= OOS areae system for remote Erans puters. S 
--- It is fu ly documented in Appendix E. * 
mae KEKKAKKRARRK : 


RAKRKKKAKKKKKAKKRKKRKAKRKKAKRRARRKERKKRKRARKAKRRKRKRRAR 


-- PROC user3 
PROC user3 = 
-- constants and variables declarations 
DEF sizetable = TABLE [ 1, 2, 4, 8, 16, 32, 64). 126>302ccneu 
1024, 1280, 2048, 4096 |: 


DEF nr.of.sizes = 14: --- # of entries in the above table 
DEF maxblock.size = 4096: “== Max EnOm Sie avOve mbar: 
VAR answer [BYTE 2] : “== user's choice in continue or quit 


VAR dummy0{[1] 
VER, “re Det ie1Onm 


-- PROC transter0O 
PROC transrer0O = 
-- variable declarations 
VAR olock.size, 
cho [BYTE 2]: : 
VAR buffer0O [BYTE maxblock.size + 1]: 


SEQ 
= indtl ala Zotton Obs ouineens 
See k = [1 FOR maxblock.size + 1] 


E 
Baereeo fay ibe kh 4. 0s 
Shite 


SEQ 1 = [0 FOR nr.of.sizes|] 
SE 


LOCK S126 =e esizecaore lis 


receive (120,ch0,dummy0) 
receive ‘150 bufferd, ummy0 ) 
SKIP 


== JOUEDUL /LOUSOULMcuanne ts 
SEQ 3 = [1 FOR repetition] 
S=z0 
receive (120,ch0,dummy0) | 
send(80,10,buffer0,1,5lock.size) 


== all outpuc sande no Umednepatamne 
SEQ 7 = [1 FOR repetition] 
Sua 


eee (120,ch0, dummy0 ) 
receive (120,buffer0,dummy0) 
send(80,10,buffer0,1,block.size) 
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-- main program 


SEO — 
bepebitelon == 20 
answer [BYTE “| := 'Y! 
RULE answer|BYTE 1} = 'Y'! 
transfer0 
receive (120,answer,dummy0) 
PAR 
operating.system 
user3 : 


Sis, 


-- configuration 
-- Link Definitions 
Te EOSUe = : 
Linklout 
Link2out 
PMc SOuUt 
LinkOin 
Teaeb ial gl 
link2in 
Pinksan 


Hou et 
“IMHO AWN © 


-- Variables 
DEE = roet — 10; 
DEF max.pipes = 20: 

CHAN pipe [max. sipes]: 


and Constants Declarations 


PLACED PAR 
== PROCESSOR Toot 


PROCESSOR Toor 
PLACE pipe[0 
FLACE Pipel2 
PLACE pipe/4 
PLACE pipe|6 
PLACE pipes 
PEACE -bipe 
SEAR ee pipet 
PLACE pipe, 


hostproc (pipe 
ipe 


ss 


linkOin 
linklin 
bel vaee 
link3in 
linkOout 
linklout 
linkZout : 
link3out 


pipes | Bipe ta 


,pipe [6 
»pipe|3],pipe 5 : 


»pipe|7? 


4°5,6,7,0,0,080)0, 070 0,0/6R0, 0,0, 0) 


== JEROCESSOR. 0 

PROCESSOR © 
PLACE pipe([1l 
PLACE pipe|9 
FLoce, paper” 
PLACE pipe{8& 


transfer0.b003 


==" PROCHOOOR d 

PROCESSOR 1 
PLACE pipe([3 
PLACE pipe|1 
PLACE pipe(2 
PLACE pipe 


transferl.b003 


== PROCRoOOR 

PROCESSOR 2 
PLACE pipe 
PLACE pipe 
PLACE Pipe 
PLACE pipe 


transfer2.b003 


OROM hh 


AT tink0on 

AT <binklin &: 
AT linkOout : 
AT linklout : 


OSs TE oso emote 
0,.655.7,0.0.0 0.0,0,4,0,0 070-0107) 


AT lLinkOin 
AT linklin 
AT linkOout 
AT linkloue 


(pipet?) Papel tee a eee 
7,0,6,5,0,0.0,0,0,0.-4,0 0 O-omananen 


AT linkOin 
AT linklin 
AT dinkoent 
AT Pinicrouwe 


(pipe LIPabe lip te eee 
57,0, 68000) 0n0R0 Oh anaronanononoman 
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-- PROCESSOR 3 

PROCESSOR 3 a 
PLACE pipe iy AT linkOin 
PLACE bibelé]. at iinkoout | 
PLACE pipe 6) AT linklout : 


transfer3.b003 (pipe [7], ,pipe({11],pipe[6],pipe[10], 
6),5, 7,0, 00" OF0"0,0,4,0,0,0,0,0,0,0) 
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